Re: [MacPerl] key event handler in dialogs

[ajf@afco.demon.co.uk (Alan Fry)]

Erik Ferranti writes Thu, 30 Apr 1998 14:03:12 -0400
>On Apr 21,  8:09am, Chris Nandor wrote:
>
>> Actually, Alan Fry did exactly this already.  I think I might have modified
>> his version slightly.  Notice that we are not actually capturing a key
>> click event here, though.  There are two text items, one visible, one
>> hidden.  In between WaitNextEvent() calls, the lengths of both are looked
>> at it; if one is longer, they are synched up.  And this synching up means
>> making the visible dialog the same number of bullets as the hidden dialog
>> has characters (and you are typing in the hidden dialog).
>
>I've been using a slightly modified version of Alan's method which works great
>except for one problem. When I hit the tab key, it appears that focus moves
>into the visible text field and then all characters typed are visible and the
>dialog returns nothing. Is there a way to mess with the tab control in the
>dialog box or can you set a hook to catch just the tab key??

You are quite right about this awful bug. In a vain attempt at self-defence
I did point it out the day after I originally posted the script. I have
subsequently concocted Password.pm which avoids dialogs altogether and
which is, I think, secure. The key strokes go nowhere near the screen. I am
sending  copy of that to Erik and if anyone else is interested please
write.

My original script also has the drawback that there is no key filtering. I
guess in most password applications strange characters probably ought to be
excluded, which requirement also raises the question of how to intercept
particular key strokes.

To intercept the tab key (for instance) you can write:

        $dlg->sethook('key', \&get_key);
        ...
        sub get_key {
            my ($dlg, $key) = @_;
            if ($key == 9) { return 1 }
            else { ??? }
        }

but the question is what to put for 'else'.

If you look at Dialogs.pm you will find the line;

        defined($handled = $_[0]->callhook("key", @_)) and return $handled;

which leads one to suppose that if you were to return 'undef', (a zero is
'defined' within the meaning of the act) the key stroke would be regarded
as 'not' handled' and passed on to the default handling procedure.

However this is defeated by a line in Hooks.pm which reads;

        $hook = "Sort of defined" unless defined ($hook);

which has the effect of always converting an undefined return to the
very-much-defined string "Sort of defined". I am not sure why this line is
there, but feel it might perhaps be better if it were not.

This line has the effect that if you intercept _any_ key, you are forced to
handle _all_ keys. Since all hook calls are similarly drafted, the same
sine qua non applies to the interception of 'clicks', 'updates', or
anything else for which one might set a hook.

In the case above you can, as it were, partially 'short-circuit' Hooks.pm
by writing;

        sub get_key {
            my ($dlg, $key) = @_;
            if ($key == 9) { return 1 }
            else { _dialogselect($key) }
        }

although the use of a 'private' function in this way will probably be
thought dubious.

Alan Fry



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch