[REBOL] Re: Disabling shortcut Keys for text field entry?
From: max:ordigraphe at: 13-Jul-2001 11:37
Hi everyone,
I've handled such a system a long, long, long time ago, when I was still
an amiga progger and at the time I was using MUI.
I needed a system where the keyboard shortcuts where dynamic, and thus
end-user-settable.
I just built a system where the shortcuts where not a list of characters
with associated effects, but rather the opposite: a list of objects
HANDLING shortcuts keypresses. so instead of having to maintain a list
of which key does what (which can have overlaps as noted by you
guys/gals already ;-)
Everytime a key was pressed and not used up by a focused gadget, I'd
traverse the list and pass the key to objects and check the return
value.
If it was non-null, then that object was the proper one and It's effects
where then called up, the list eval stopped, and the function put at the
head of the list... (recurring useage is then FASTER. Usually, a key
used once will be used again.
NOW is the cool part... I could mix-up UI keycodes AND non-ui driven
shortcuts at the same time, just by supplying other objects in the list
which returned a function (pointer) instead of 1 or 0 ! :-)
ALSO, Since object (methods) where called up, they could acknowledge the
keypress with any kind of condition or restriction. So if another
button needed a certain value, for it to work, I just checked it up and
returned null, if it wasn't set properly. This makes your action code
MUCH CLEANER, because it will only activate if VALIDATED! (but care must
taken for speed)
The same event handler handles every thing without the need for
traversing the whole (100+ items) gui list everytime its called, just
the shortcut system. And this also allows you to create ANY kind of
shortcut, even ones which focus/unfocus objects and gui events which
have more than one possible shortcut !
here is an example of a way this COULD be setup by RT for us:
when building a button... within a view layout.. EXAMPLE:
button "PRESS ME" shortcut "E" 100x20 [action-function]
which would do:
The shortcut keyword adds this object to the "shortcut function" list of
this window. By appending the default check-keycode function to the
shortcut list which points to the button object. Since its using the
button object itself, it just has to look at the object's -CURRENT-
keycode value.
you still can change the keycode value ON-THE-FLY, but this approach
will not traverse the whole gui (Which can easily contain several dozen
ui elements) when verifying keypresses.
BUT now, we can add our own custom keypress validation (by specifying a
new keyword followed by a function block) and still change the keycode
ON-THE-FLY
example:
my-validator: func [obj] [either (keypress = obj/keycode) AND
tab-is-open? [
obj/action
return true
][
return none]
]
button "PRESS ME" shortcut "E" 100x20 [action-function] validate
[my-validator]
a new function called add-shortcut could then let us add our own
shortcuts (non-ui driven) in the chain, for example:
add-shortcut my-validator-func shortcut-obj
where:
shortcut-obj: make object! [
action: show-second-tab
keycode: "A"
]
BTW, you could implement most of this already by making a custom handler
for a bogus and hidden ui object, but you'd have to add all shortcuts
using the add-shortcut scheme described above and maybe setup this
object in each pane or window ?)
hope I'm making sense.
sorry if the reply is long, It just takes a lot of words to describe
stuff clearly.
'later
-Max
