Re: vw7.7 & keyboard shortcuts
Locked
 
|
What would you like Ctrl+B to
do? (Or a better example, Ctrl+U, which isn’t mapped in the Workspace or Browser
in 7.6 or 7.7.) The understanding of VW is that
Ctrl+[A-Z] is a normal character, and so it will insert it. That’s this
line in UIFeelPolicy>>keyboardDispatchTable k
defaultForCharacters: #normalCharacterKey:. If you don’t want Ctrl+[A-Z]
to be treated as insertable characters, try adding something like this in the
next line: (((1
to: 26) copyWithout: 13 "CR") copyWithout: 11 "Compose
key") do: [:ix | k
bindValue: #ignoreInputKey: to: (Character value: ix)]. Steve From: [hidden email]
[mailto:[hidden email]] On Behalf Of Mark Plas Hi Josef, I don't think it's locale
related. The problem is that an input field first answers 'no' to the question
whether it can handle Ctrl-B, and a bit later is asked to handle it anyway and
just inserts a 'Ctrl-B character' in the input field. It should insert nothing at all. I use ctrl-B as an example, but
any ctrl-<key> combination will result in this if it cannot be handled by
an input field and cannot be handled by the menu bar. I'm not sure I understand your
remark concerning the keyboardHook. The possible issue I see is that it runs a
risk of not getting evaluated if there is a menu item in the menu bar that can
handle the keyboard shortcut. This is not what I would expect, given that the
keyboard event handling algorithm was changed to give priority to the widget
first and only thereafter to the menu bar. Mark From: Josef Springer
[mailto:[hidden email]] Hi Mark, Hello, I'm trying to upgrade from vw7.4.1 to vw7.7. In vw7.7 the handling of keyboard events has changed a bit
and I'm attempting to change our code to conform to this new way. The way vw7.7 handles keyboard events can be seen in
KeyboardProcessor>>processKeyboardEvent: and can be described like this: First the
'currentConsumer' is asked to handle a keypress/release and if he can handle
it, he's told to handle it. Next, if the
'currentConsumer' says he cannot handle it, the menubar is asked to handle it. Lastly, If the menubar
can't handle it, the currentConsumer again comes into play and is told to
handle the event without asking whether he wants to. This causes some problems in our application. When, for
instance, I press ctrl-B in an input field, a black rectangle appears.
The reason for this can be seen by going through the algorithm above: First the input field is
asked whether it can handle ctrl-B. It answers false because ctrl-B is not
mapped in its dispatch table. Next the menubar is asked
whether it can handle ctrl-B. It answers false because I have no menu items
with a ctrl-B shortcut. Lastly, the input field
is told to handle ctrl-B. This time, it doesn't check whether ctrl-B is in the
dispatch table, so it just inserts a 'ctrl-B' character in the input field,
which gets displayed as a black rectangle. How can I avoid this? Something else which is not clear to me is how the
#keyboardHook on a TextEditorController gets taken into consideration. Suppose I have an input field with a keyboardHook that can
handle Ctrl-B and suppose I also have a menu item that can handle ctrl-B, then,
if we go through the algorithm again, this happens: First the input field is
asked whether it can handle ctrl-B. It answers false because ctrl-B is not
mapped in its dispatch table. Even though the keyboardHook can handle it, it's
not asked to handle it. Next the menubar is asked
whether it can handle ctrl-B. It answers true and handles the Ctrl-B. The input field is no
longer told to handle the keyboard event because the menubar took care of it. Result: my input field didn't get the chance to handle
Ctrl-B, which I wouldn't expect given that the keyboardEvent handling algorithm
was changed to give priority to the currentConsumer. How do I avoid the black rectangles and is it normal that
the keyboardHook on an input field doesn't come into play? Thanks, Mark _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Hi Steven, We have our own
keyboardDispatchTable for our application and I want Ctrl+B to do nothing
(actually, ctrl-<almostAnyKey> should do nothing). In the past we added a
line like you suggested to map all Ctrl-key combinations to #ignoreInputKey:,
and this used to work fine because in vw7.4.1 first the menu bar was given the
chance to handle Ctrl-<key> and in case no Ctrl-<key> menu item
existed, the current input field got the Ctrl-<key> and this was mapped
to do nothing. This worked fine. But in VW7.7 this
technique doesn't work anymore, because when I now map all Ctrl-<key>
combinations to #ignoreInputKey:, then the InputField thinks that it wants to
handle the keyboard shortcut – since there is a mapping for it in its
dispatchTable – and doesn't let the menu bar handle it anymore. So all of
a sudden I can no longer use any Ctrl-key shortcut combination to perform menu
actions when an input field has keyboard focus because the input field eats all
Ctrl-key presses. Which is not what I want. So I decided to NOT map
the Ctrl-<key> combinations in the dispatchTable. This way the inputfield
doesn't mistakenly think that it should handle the keyboard event, and my menu
items can still be performed using the Ctrl-<key> combination. Only
problem then is that when there is no menu item handling the shortcut, the
inputfield is forced to handle it anyway resulting in unwanted behavior and a
black rectangle in the inputfield. How can I get around
this (without changing base code)? Mark From:
[hidden email] [mailto:[hidden email]] On Behalf Of Steven
Kelly What would you like
Ctrl+B to do? (Or a better example, Ctrl+U, which isn’t mapped in the
Workspace or Browser in 7.6 or 7.7.) The understanding of
VW is that Ctrl+[A-Z] is a normal character, and so it will insert it.
That’s this line in UIFeelPolicy>>keyboardDispatchTable
k defaultForCharacters: #normalCharacterKey:. If you don’t
want Ctrl+[A-Z] to be treated as insertable characters, try adding something
like this in the next line:
(((1 to: 26) copyWithout: 13 "CR") copyWithout: 11 "Compose
key") do: [:ix |
k bindValue: #ignoreInputKey: to: (Character value: ix)]. Steve From:
[hidden email] [mailto:[hidden email]] On Behalf Of Mark
Plas Hi Josef, I don't think it's
locale related. The problem is that an input field first answers 'no' to the
question whether it can handle Ctrl-B, and a bit later is asked to handle it
anyway and just inserts a 'Ctrl-B character' in the input field. It should insert
nothing at all. I use ctrl-B as an
example, but any ctrl-<key> combination will result in this if it cannot
be handled by an input field and cannot be handled by the menu bar. I'm not sure I
understand your remark concerning the keyboardHook. The possible issue I see is
that it runs a risk of not getting evaluated if there is a menu item in the
menu bar that can handle the keyboard shortcut. This is not what I would
expect, given that the keyboard event handling algorithm was changed to give
priority to the widget first and only thereafter to the menu bar. Mark From:
Josef Springer [mailto:[hidden email]] Hi Mark, Hello, I'm trying to upgrade from vw7.4.1 to
vw7.7. In vw7.7 the handling of keyboard events
has changed a bit and I'm attempting to change our code to conform to this new
way. The way vw7.7 handles keyboard events can
be seen in KeyboardProcessor>>processKeyboardEvent: and can be described
like this: First
the 'currentConsumer' is asked to handle a keypress/release and if he can
handle it, he's told to handle it. Next, if
the 'currentConsumer' says he cannot handle it, the menubar is asked to handle
it. Lastly,
If the menubar can't handle it, the currentConsumer again comes into play and
is told to handle the event without asking whether he wants to. This causes some problems in our
application. When, for instance, I press ctrl-B in an input field, a
black rectangle appears. The reason for this can be seen by going through the
algorithm above: First
the input field is asked whether it can handle ctrl-B. It answers false because
ctrl-B is not mapped in its dispatch table. Next the
menubar is asked whether it can handle ctrl-B. It answers false because I have
no menu items with a ctrl-B shortcut. Lastly,
the input field is told to handle ctrl-B. This time, it doesn't check whether
ctrl-B is in the dispatch table, so it just inserts a 'ctrl-B' character in the
input field, which gets displayed as a black rectangle. How can I avoid this? Something else which is not clear to me is
how the #keyboardHook on a TextEditorController gets taken into consideration. Suppose I have an input field with a
keyboardHook that can handle Ctrl-B and suppose I also have a menu item that
can handle ctrl-B, then, if we go through the algorithm again, this happens: First
the input field is asked whether it can handle ctrl-B. It answers false because
ctrl-B is not mapped in its dispatch table. Even though the keyboardHook can
handle it, it's not asked to handle it. Next the
menubar is asked whether it can handle ctrl-B. It answers true and handles the
Ctrl-B. The
input field is no longer told to handle the keyboard event because the menubar
took care of it. Result: my input field didn't get the
chance to handle Ctrl-B, which I wouldn't expect given that the keyboardEvent
handling algorithm was changed to give priority to the currentConsumer. How do I avoid the black rectangles and is
it normal that the keyboardHook on an input field doesn't come into play? Thanks, Mark _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
| Free forum by Nabble | Edit this page |