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

Disabling shortcut Keys for text field entry?

 [1/13] from: agem::crosswinds::net at: 9-Jul-2001 15:59


RE: [REBOL] Re: Disabling shortcut Keys for text field entry? Hi Brett. there is a place for flags in vid-faces, like 'wrap. 'flag-words ? how about a 'dissable-hotkeys there instead of removing handler? :) ;-) Volker [brett--codeconscious--com] wrote:

 [2/13] from: brett:codeconscious at: 10-Jul-2001 0:30


Hi Volker, I didn't remove the handler just modified it's behaviour a little :) Regarding flags, yes using a flag sounds like it would be a really good way to go. But I've not investigated flags in vid-faces so I'm not sure what the issues (if any are). I think something like a dissable-hotkeys would be a good idea, but without doubt there will be some hotkeys that should work even in a field for example F1 to initiate a help screen say. I'm aware that the more functionality added for this the more potential of a hit performance wise though. Any ideas for a simple way to make shortcut keys specific? Maybe a global group of shortcut keys that affect everything and some specific groups that particular faces can belong to? Just wondering... Brett.

 [3/13] from: agem:crosswinds at: 9-Jul-2001 19:12


RE: [REBOL] Re: Disabling shortcut Keys for text field entry? Hi Brett [brett--codeconscious--com] wrote:
> Hi Volker, > > I didn't remove the handler just modified it's behaviour a little :) > > Regarding flags, yes using a flag sounds like it would be a really good way > to go. > But I've not investigated flags in vid-faces so I'm not sure what the issues > (if any are). >
layout[ ar: area ] probe ar/flags == [tabbed] this could be is a good place for other flags?
> I think something like a dissable-hotkeys would be a good idea, but without > doubt there will be some hotkeys
<<quoted lines omitted: 5>>
> Maybe a global group of shortcut keys that affect everything and some > specific groups that particular faces can belong to?
how much is known about the face of the hotkey? could we say if any[find hotkey-panel key not in-text-face][allow-hotkey] ? then we make a panel with file & copy-paste menu and one with the 'next-picture -stuff
> Just wondering... > > Brett. >
-Volker

 [4/13] from: g:santilli:tiscalinet:it at: 9-Jul-2001 19:38


Hello Brett! On 09-Lug-01, you wrote: 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: 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. Just thinking loud, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [5/13] from: brett:codeconscious at: 10-Jul-2001 11:30


> > Any ideas for a simple way to make shortcut keys specific? > >
<<quoted lines omitted: 7>>
> then we make a panel with file & copy-paste menu > and one with the 'next-picture -stuff
I'm sorry Volker - I don't understand. I must need more coffee :) Which is the face of the hotkey, and what is the 'next-picture stuff ? Brett.

 [6/13] from: brett:codeconscious at: 10-Jul-2001 12:47


Hi Volker,
> my thought was
.... Thanks, much clearer. You use a face to gather together all the "globally" active hotkey type faces. By classing them specially they always get through removing the need for blocks on everything else. Great approach. Combined with the flag stuff could be enough to satisfy the original problem. Now I'm intrigued to see what else can be done :) Brett.

 [7/13] from: agem:crosswinds at: 10-Jul-2001 4:08


RE: [REBOL] Re: Disabling shortcut Keys for text field entry? Hi Brett, [brett--codeconscious--com] wrote:
> > > Any ideas for a simple way to make shortcut keys specific? > > >
<<quoted lines omitted: 11>>
> I'm sorry Volker - I don't understand. I must need more coffee :) > Which is the face of the hotkey, and what is the 'next-picture stuff ?
um. yes, i was very clear, i see.. :-| my thought was: lets say we have a layout with a sub-layout for global hotkeys, an area for text and another sub-layout with an image and some hotkeys for it (for example). a layout has a pane with some faces. we can check if a face is in a pane with find. so we can use that for grouping: any[ if find global-hotkeys/pane face-with-hotkey[do-it] if not editing-text [do-it] ;we are editing, ignore (image-hotkeys and co.) ] if the event-handler knows the face with the hotkey. i hope it does? usually i have a button-menu with hotkeys which is global. i thought i could use a panel for it. now i prefer an explicit block with this faces. faces-blocks could be better than hotkey-blocks because faces can be named?
> Brett. >
-Volker

 [8/13] 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
<<quoted lines omitted: 3>>
> 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
<<quoted lines omitted: 16>>
> 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

 [9/13] from: g:santilli:tiscalinet:it at: 10-Jul-2001 19:31


Hello Brett! On 10-Lug-01, you wrote: BH> One nice property at the moment, that Volker demonstrated so BH> well, is that if you set a keycode of a face at any time it BH> becomes active. Further, I found that setting the keycode of BH> a face to a function works. In effect, every face is a BH> listener for keycodes but only one of them (the first that BH> responds) handles it. This would be lost, I think, if you had BH> to maintain a key-face table as well. That's true. It's just that I find it not really that efficient to traverse the whole face tree for any pressed key, even if there are no keycodes defined. BH> I thought of a charset too, but we probably need more than BH> just a charset in order to handle things like F1 which is a BH> keycode of type word!. Yep... BH> Thanks for sharing your thoughts! Thank you for taking them into consideration. :) Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [10/13] 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

 [11/13] from: dm128:microconnect at: 7-Jul-2001 2:55


I am using short-cut keys with button in REBOL/View is there a way I can disable them while I have a user entering text in a field? layout [ field "enter text here" button "Click me" #"c" [Unrelated code] ] Thank you, Dave

 [12/13] from: agem:crosswinds at: 7-Jul-2001 17:23


RE: [REBOL] Disabling shortcut Keys for text field entry? [dm128--microconnect--net] wrote:
> I am using short-cut keys with button in REBOL/View is there a way I can > disable them while I have a user entering text in a field? > > layout [ > field "enter text here" > button "Click me" #"c" [Unrelated code] > ] >
[rebol [] la: layout [ button "quit" [quit] ;button "disable" [bu/keycode: none] ;button "enable" [bu/keycode: #"z"] bu: button {#"z"} #"z" "hi" [alert "ping!"] field "to click somewhere else" ar: area {disable hotkey, press #"z" here :)} feel [ ;have to keep old bindings, so patch redraw: func [face act pos] append second :redraw [ either face = system/view/focal-face [ bu/keycode: none ] [ bu/keycode: #"z" ] ] [;original redraw: func [face act pos] [ if all [in face 'colors block? face/colors] [ face/color: pick face/colors face <> view*/focal-face ] ] ]] ] source focus source unfocus probe ar/feel view center-face la ]
> Thank you, > Dave >
;-) Volker

 [13/13] from: brett:codeconscious at: 8-Jul-2001 18:12


Here's another way. You could change the detect function of system/view/window-feel which is reponsible for handling shortcut keys. I've put an example below. My example is bloated by some supporting code that allows me to install the change and uninstall it again later. The bit that makes it work is the function "install-nofieldshortcuts". Note that in the version of the code shortcuts are "turned off" for fields but still operational for areas so you can compare. install-nofieldshortcuts: does [ system/view/window-feel: make system/view/window-feel [ detect: func [face event] [ either all [ event/type = 'key system/view/focal-face system/view/focal-face/style equal? system/view/focal-face/style 'field ] [event] [old-detect face event] ] old-detect: get in system/view/window-feel 'detect ] ] uninstall-nofieldshortcuts: does [ use [wf] [ wf: system/view/window-feel set in wf 'detect get in wf 'old-detect ] ] view layout [ button "press" #"a" [print "button pressed - a"] field do [ print "Installing shortcut trap" install-nofieldshortcuts print "Installing event function" evtfunc: insert-event-func [ if equal? event/type 'close [ print "Removing shortcut trap" uninstall-nofieldshortcuts print "Removing event function" remove-event-func :evtfunc ] RETURN event ] ] ] HTH Brett.

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted