[REBOL] Re: Disabling shortcut Keys for text field entry?
From: brett:codeconscious at: 10-Jul-2001 12:58
Hi Gabriele,
Thanks for your reply and thanks for thinking through a solution.
> BH> Any ideas for a simple way to make shortcut keys specific?
>
> - patch LAYOUT so that keys are collected in a key-face table
> - patched LAYOUT puts the table in the window's face and puts
> up a handler that looks in the table for keys
> - the window face should also contain a charset that says wich
> keys should be catched even when a field/area is active
> - the handler just has to:
I'd be reluctant to rely on Layout as it would be nice to see it work for
manually created view faces as well.
One nice property at the moment, that Volker demonstrated so well, is that
if you set a keycode of a face at any time it becomes active. Further, I
found that setting the keycode of a face to a function works. In effect,
every face is a listener for keycodes but only one of them (the first that
responds) handles it. This would be lost, I think, if you had to maintain a
key-face table as well.
I thought of a charset too, but we probably need more than just a charset in
order to handle things like F1 which is a keycode of type word!.
> either system/view/focal-face [
> ; there's an active face. catch only keys in charset
> ] [
> ; no active face; catch any key in table
> ]
>
> Notice that not only Fields and Areas may become active. Text
> become active too for clipboard operation; you might want to
> disable normal keys only when a Field or similar face is active;
> you could check the face's flags:
>
> either flag-face? system/view/focal-face wants-keys [
> ; ...
> ] [
> ; ...
> ]
>
> and you can:
>
> flag-face get-style 'field wants-keys
> flag-face get-style 'area wants-keys
>
> before the user creates any custom style, so that if (s)he derives
> one of its styles from Field or Area (s)he will get correct keys
> behavious on them too.
Yes Volker mentioned flags. Seems quite reasonable.
I guess this issue all comes about from the way that the shortcut keys are
handled before the focussed face even sees them, requiring us in some cases
to prevent the shortcut key processing and instead pass the key onto the
focussed face for processing. If instead, the focussed face instead had
first go at the key it could have decided to pass it up to shortcut key
processing or just handle it itself.
Think I need to reflect on this a little more. :)
> Just thinking loud,
> Gabriele.
Thanks for sharing your thoughts!
Brett
