Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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