1. Use a separate frame or dialog (without an accelerator table or menubar) for collecting the keystroke from the user. Since that frame/dialog won't have any active accelerators then there's nothing to steal the event before it's sent as a key event. This is how most apps on all platforms and toolkits that I've seen that collect keystrokes like this do it.
2. You can rebuild the menubar and menus without the '&' or '\t<keyname>' in the items, and then rebuild the original menus when done.
···
On 9/16/09 9:16 AM, Bryan Oakley wrote:
On Wed, Sep 16, 2009 at 11:04 AM, Mike Driscoll<mike@pythonlibrary.org> wrote:
Hi Bryan,
I thought I'd take a whack at this. Check out my attached example and see if
it does what you're talking about.
Thanks for trying, but no, it doesn't do what I want.
Using your code as a starting point, what I require is that when in
the first text field, alt-f does *not* bring up the file menu, whereas
if focus is in the second text field it does.
And to make it maybe even easier to grok, change the label of the
refreshMenuItem to be "Refresh\tF1" so that F1 does a refresh. Then,
modify the code so that F1 does not do the refresh when focus is in
the first text field but does when it is in the second, and even when
focus is in the first I should be able to click on the refresh item on
the menu (read: refresh isn't disabled, but F1 is)
So again, I want to disable *all* accelerators (but not the menuitems)
when focus is in the first text control.
1. Use a separate frame or dialog (without an accelerator table or
menubar) for collecting the keystroke from the user. Since that
frame/dialog won't have any active accelerators then there's nothing to
steal the event before it's sent as a key event. This is how most apps
on all platforms and toolkits that I've seen that collect keystrokes
like this do it.
Thanks for the suggestion, Robin. I don't think I'll go that route.
IMO dialogs should be avoided like the plague, and I don't think I'll
throw one up just to work around this issue. I've apparently had the
opposite experience to you -- I've seen this functionality embedded in
other windows on more than one occasion.
Funny though...just to prove my point I popped up the gnome keyboard
accelerator program. It lets me press keys and it captures the key
without doing the action. I'll get a dialog saying "that key is
already bound to action <foo>" instead of it actually doing that
action. However, this dialog suffers from the exact problem I'm trying
to solve. If I type alt-c for one of the actions it will instead close
the dialog since that's what's assigned to the close button. That's
bad UI IMO. Here I thought I was associating alt-c with a function and
instead it closed the program. Surprise!
2. You can rebuild the menubar and menus without the '&' or
'\t<keyname>' in the items, and then rebuild the original menus when done.
Thanks for the suggestion. That sounds a bit too hackish. If this
functionality isn't supported I'll just design something slightly
different. This should have been a five minute problem but I've
wasted half a day on it. Time to just make the user type "F1" rather
then press the F1 key and be done with it.
<shrug>
<shrug>
···
On Wed, Sep 16, 2009 at 1:52 PM, Robin Dunn <robin@alldunn.com> wrote:
That is probably yet another layer of accelerators in play, the Window Manager's. On X11 even if the application is able to avoid triggering its own accelerators the Window Manager's will already have been processed before it gets to the application.
···
On 9/16/09 12:31 PM, Bryan Oakley wrote:
Funny though...just to prove my point I popped up the gnome keyboard
accelerator program. It lets me press keys and it captures the key
without doing the action. I'll get a dialog saying "that key is
already bound to action<foo>" instead of it actually doing that
action. However, this dialog suffers from the exact problem I'm trying
to solve. If I type alt-c for one of the actions it will instead close
the dialog since that's what's assigned to the close button. That's
bad UI IMO. Here I thought I was associating alt-c with a function and
instead it closed the program. Surprise!
I don't think that's true in this case. C was simply the accelerator
for the cancel button, it wasn't related to the window manager.
Regardless, I could live with not preventing window manager events,
but for an app not to be able to deal with its own events seems a bit
odd.
This may be a limitation in gtk rather than wx or wxPython, but it's
not a limitation of all windowing toolkits. Unfortunately I'm stuck
with wxPython for this particular application.
<shrug>
···
On Wed, Sep 16, 2009 at 5:58 PM, Robin Dunn <robin@alldunn.com> wrote:
On 9/16/09 12:31 PM, Bryan Oakley wrote:
Funny though...just to prove my point I popped up the gnome keyboard
accelerator program. It lets me press keys and it captures the key
without doing the action. I'll get a dialog saying "that key is
already bound to action<foo>" instead of it actually doing that
action. However, this dialog suffers from the exact problem I'm trying
to solve. If I type alt-c for one of the actions it will instead close
the dialog since that's what's assigned to the close button. That's
bad UI IMO. Here I thought I was associating alt-c with a function and
instead it closed the program. Surprise!
That is probably yet another layer of accelerators in play, the Window
Manager's. On X11 even if the application is able to avoid triggering
its own accelerators the Window Manager's will already have been
processed before it gets to the application.