Yeah...I think I understand that...but shouldn't "jump tables" defined within a package that access (use) ancestor functions use @ISA?

None of my "("two or one, since timer is currently 'disabled'")" Tk event handler routines rely on searching @ISA. The handler is in the same "class" (package) as the "bind" statement that is 'binding' it to Tk. As for associating the method's invocation with the correct instance, I only allow 1 instance of an "open database" per program. So any methods called by Tk refer to the 1 program-wide instance (any wonder why global variables in the none OO were so useful?... but also, so constraining).

The key handler makes an indirect call (or two). The entire code snipplet (which I plan on simplifying, later, once I get it "working" again -- I started from the linear, working 'proof-of-concept' code that was my first "version" of this program, but bound to '<Any_Keypress>', is this routine:

    sub __handle_key {
        my ( $s, $key_event, $key_code) = @_[1..3];
        my $image_win = $s->image_win;
    #    use Readonly;
    
        Readonly my $single_key_commands => "\003\015\033 +-0123456789
+RWbnpq";
        
        Readonly my    @single_key_functions => ( 
                        \&_abort, \&next_rand_or_recorded_entry, 
                        \&_abort, \&_space, 
                        \&inc_cur_rating, \&dec_cur_rating,
                        \&_set_rating, \&_set_rating, \&_set_rating,
                        \&_set_rating, \&_set_rating, \&_set_rating,
                        \&_set_rating, \&_set_rating, \&_set_rating,
                        \&_set_rating,
                        \&_reset_to_beginning_entry, \&write_db,
                        \&backup_entry, \&next_rand_or_recorded_entry,
+ 
                        \&_pause, \&_quit
                    );
        Readonly my @key_code_commands => qw( Left Up Right Down Home 
+KP_Home);
        Readonly my @key_code_functions => (
                        \&backup_entry,\&backup_entry,
                        \&next_rand_or_recorded_entry, \&next_rand_or_
+recorded_entry,
                        \&_set_to_beginning_entry,
                        \&_set_to_beginning_entry,
                );
      KEY_SWITCH:
        {    
            if ($key_event ne '') {
                my $active_key=index $single_key_commands, $key_event;
                if ($active_key >=  0 ) {
                    $single_key_functions[$active_key] -> 
                                                ($s, $key_event, $key_
+code);
                    last KEY_SWITCH;
                }
            } else {    # ($key_event eq '') 
                # ignore modkeys
                return if ($key_code =~ /^(?:Shift|Control|Alt)_[RL]$/
+ ||
                    $key_code =~ /^(:Shift|Num|Scroll)_Lock$/); 
                ($key_code eq '') && do { # null event
                    carp("key handler called with no key data\n");
                    error_beep(); 
                    return;
                };
                my $active_key_code=_str_index @key_code_commands, $ke
+y_code;
                if ($active_key_code >= 0) {
                    $key_code_functions[$active_key_code] -> 
                                                ($s, $key_event, $key_
+code);
                    last KEY_SWITCH;
                }
            }
            {    # default (unhandled/unexpected key)
                printf "Unrecognized key \'%s\', code \'%s\'\n", $key_
+event,
                  $key_code;
                error_beep(); return;
            };
    
        }    # end KEY_SWITCH;
    
        if ($s->disable_auto_advance()) {
            alarm 0;
            $s->timer_enabled(0);
        } else {
            $s->timer_ticked(0);
            alarm $s->auto_advance_time;
            $s->timer_enabled(1);
        }
    
        $s->show_cur_entry_in_imgwin();
      
    }
[download]

Handle_key is what is making some of the "unfound" calls at this point -- the routines in the "jump table"...but it does not seem the jump table is at fault, since "q" (the quit action) properly calls the _quit function:    sub _quit() { $_[0]->write_db(); exit 0; } and fails trying to call "write_db" on exit. "write_db" is a method in a parent class.

Regardless of call syntax, Perl isn't searching my @ISA info for parent classes. If I am in the debugger before the "$s->write_db()" statement in "_quit()" and use the debugger's "m" command to print out available methods, it finds the parental method, but not when executed.

Perhaps this is a bug? I.e. shouldn't the debugger be using the same search method as that used during regular execution?
L