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