key events... hacking...

hi gang! Is anyone capable of getting keyboard events for faces which are not "focused", short of rewriting the whole event handler? I need to handle shortcuts in a multi-level ui system. The problem right now is that if I focus a face, then the caret appears and its looks mimic a text field! I'd just want a way to get keyboard events at their source and if they coincide with a specific current setup or context, then an action is called... does the key style allow me to do just that, and if so, do any one of you have simple useage examples... its been a while since I've been in keyboard hassles dept. thanks in advance! AND A BIG THAKS TO EVERYONE WHO SHARED A SECRET OR TWO ABOUT VID ACCELERATION. I am sure many novices and a few veterans learned at least one or two tricks. Thats what I wanted, to get that kind of info shared in one continous stream. now may be gerard or cybarite will compile that somewhere ;-) as if we don't all have enough to do already. CHEERS! -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

Try something like: insert-event-func func [ face event ][ If event/type = key [ ;do something ] ] HTH ~~Ammon ;-> ----- Original Message ----- From: "Maxim Olivier-Adlhoch" <[maximo--meteorstudios--com]> To: "Rebol-List (E-mail)" <[rebol-list--rebol--com]> Sent: Tuesday, January 20, 2004 4:23 PM Subject: [REBOL] key events... hacking...

> hi gang! > > Is anyone capable of getting keyboard events for faces which are not

> I need to handle shortcuts in a multi-level ui system. The problem right

> I'd just want a way to get keyboard events at their source and if they

> does the key style allow me to do just that, and if so, do any one of you

> thanks in advance! > > AND A BIG THAKS TO EVERYONE WHO SHARED A SECRET OR TWO ABOUT VID

sooooo simple! THANKS! Does the return value indicate if the event should be passed along to the next event handler? or anything of the like... -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

Hi Max, MOA> Does the return value indicate if the event should be passed MOA> along to the next event handler? or anything of the like... Yes. You are hooking into an event chain so you must return the event itself. e.g. insert-event-func func [face event] [ print [event/1 event/2 event/3 event/4 event/5 event/6 event/7 event/8] event ] Also, look into remove-event-func if you're doing more than simple single-shot View window stuff. -- Gregg

Hi Maxim, On Wednesday, January 21, 2004, 12:23:35 AM, you wrote: MOA> Is anyone capable of getting keyboard events for faces MOA> which are not "focused", short of rewriting the whole event MOA> handler? This is a modified window feel I use in some applications; it allows to focus any face using CUSTOM-FOCAL-FACE. You just need to set it to the face you want to focus. (You might want to discard all the other changes.) ; support for custom-focal-face insert tail second :unfocus [ if object? get/any 'custom-focal-face [custom-focal-face: none]] ; new window feel, to catch active, inactive and close. ; update: catch keys too, but without interfering with focused faces; ; also, now the whole event is passed to window/action ; update: now ESC unfocuses, too ; update: custom-focal-face added system/view/window-feel: make system/view/window-feel [ detect: func [face event /local f] [ either event/type = 'key [ either all [system/view/focal-face in-window? face system/view/focal-face] [ if event/key = #"^(1B)" [ unfocus] event ] [ either all [object? get/any 'custom-focal-face in-window? face custom-focal-face] [ custom-focal-face/feel/engage custom-focal-face 'key event none ] [ do-face face event either f: find-key-face face event/key [ do-face f event none ] [ event] ] ] ] [ if find [close active inactive] event/type [ do-face face event] event ] ] ] Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

thanks! this works for me. but I noticed I have to patch in-window? cause there is a bug in it (v1.2.10)! if you source the code, you will notice that the last call to in-window is incorrectly typed as in-window instead of in-window? here is fixed version... for those who are listening: in-window?: func [ "Return true if a window contains a given face." window face ][ if face = window [return true] if none? face/parent-face [return false] in-window? window face/parent-face ] -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

Hi Maxim, On Wednesday, January 21, 2004, 10:12:47 PM, you wrote: MOA> but I noticed I have to patch in-window? cause there is a bug in it (v1.2.10)! MOA> if you source the code, you will notice that the last MOA> call to in-window is incorrectly typed as in-window instead MOA> of in-window? Yup, I have a patched version in the same script as that other code. I forgot to include it too. :) Anyway, it is fixed in the new View.

>> about

>> source in-window?