[wxPython-users] Problem with grid cell editorHi all,
I am using a wxAcceleratorTable to trap Ctrl-F. I thought it was working perfectly, on both MSW and GTK2, but I have just found a problem with GTK2.
It works if NumLock is off. If I switch it on, Ctrl-F is not detected. Platform is Redhat 9/Python 2.2.3/wxPython 2.4.1.2u compiled for GTK2.
Any assistance will be appreciated.
Frank Millman
Frank Millman wrote:
[wxPython-users] Problem with grid cell editorHi all,
I am using a wxAcceleratorTable to trap Ctrl-F. I thought it was
working perfectly, on both MSW and GTK2, but I have just found a
problem with GTK2.It works if NumLock is off. If I switch it on, Ctrl-F is not
detected. Platform is Redhat 9/Python 2.2.3/wxPython 2.4.1.2u
compiled for GTK2.
For some reason the NumLock is by default treated as nother modifier key by XFree86, Meta I think. So when the key event happens it looks like Ctrl-Meta-F instead of just Ctrl-F and so the accelerator is not triggered.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Frank Millman wrote:
>Hi all,
>
> I am using a wxAcceleratorTable to trap Ctrl-F. I thought it was
> working perfectly, on both MSW and GTK2, but I have just found a
> problem with GTK2.
>
> It works if NumLock is off. If I switch it on, Ctrl-F is not
> detected. Platform is Redhat 9/Python 2.2.3/wxPython 2.4.1.2u
> compiled for GTK2.
Robin Dunn wrote:
For some reason the NumLock is by default treated as nother modifier key
by XFree86, Meta I think. So when the key event happens it looks like
Ctrl-Meta-F instead of just Ctrl-F and so the accelerator is not
triggered.
Thanks, Robin, for the explanation. However, you did not suggest a
workaround. As you may recall, I am writing an accounting application, where
a user typically ensures that NumLock is on at the beginning of a session
and leaves it on the whole time. Therefore it is important to get a solution
to this.
I tried using Alt-F instead of Ctrl-F. It worked, but then I found an even
worse problem. If NumLock is on, 'f' triggers the accelerator even if Alt is
not down, so you cannot type an 'f' into any text control! The same applies
to any character I put into the wxAcceleratorTable.
BTW, the following is from the documentation for wxKeyEvent::HasModifiers -
"Returns TRUE if either CTRL or ALT keys was down at the time of the key
event. Note that this function does not take into account neither SHIFT nor
META key states (the reason for ignoring the latter is that it is common for
NUMLOCK key to be configured as META under X but the key presses even while
NUMLOCK is on should be still processed normally)."
I guess what I am asking for is something similar - ignore the META key
state for wxAcceleratorTable.
Do you have any suggestions?
Thanks in advance.
Frank
Frank Millman wrote:
Frank Millman wrote:
Hi all,
I am using a wxAcceleratorTable to trap Ctrl-F. I thought it was working perfectly, on both MSW and GTK2, but I have just found a problem with GTK2.
It works if NumLock is off. If I switch it on, Ctrl-F is not detected. Platform is Redhat 9/Python 2.2.3/wxPython 2.4.1.2u compiled for GTK2.
Robin Dunn wrote:
For some reason the NumLock is by default treated as nother modifier key by XFree86, Meta I think. So when the key event happens it looks like Ctrl-Meta-F instead of just Ctrl-F and so the
accelerator is not triggered.Thanks, Robin, for the explanation. However, you did not suggest a workaround. As you may recall, I am writing an accounting application, where a user typically ensures that NumLock is on at the
beginning of a session and leaves it on the whole time. Therefore it
is important to get a solution to this.
Try making two entries in the accelerator table, one for Ctrl-F and one for Ctrl-Alt-F. The other option of course is to change the xmodmap so Numlock is not Meta, but that would have to be done external to your app.
I tried using Alt-F instead of Ctrl-F. It worked, but then I found an
even worse problem. If NumLock is on, 'f' triggers the accelerator even if Alt is not down, so you cannot type an 'f' into any text control! The same applies to any character I put into the wxAcceleratorTable.
It looks like wxWindows maps Meta to Alt.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
>> Frank Millman wrote:
>>
>>> Hi all,
>>>
>>> I am using a wxAcceleratorTable to trap Ctrl-F. I thought it was
>>> working perfectly, on both MSW and GTK2, but I have just found a
>>> problem with GTK2.
>>>
>>> It works if NumLock is off. If I switch it on, Ctrl-F is not
>>> detected. Platform is Redhat 9/Python 2.2.3/wxPython 2.4.1.2u
>>> compiled for GTK2.
>
>
> Robin Dunn wrote:
>
>> For some reason the NumLock is by default treated as nother
>> modifier key by XFree86, Meta I think. So when the key event
>> happens it looks like Ctrl-Meta-F instead of just Ctrl-F and so the
>> accelerator is not triggered.
>
>
> Thanks, Robin, for the explanation. However, you did not suggest a
> workaround. As you may recall, I am writing an accounting
> application, where a user typically ensures that NumLock is on at the
> beginning of a session and leaves it on the whole time. Therefore it
> is important to get a solution to this.Try making two entries in the accelerator table, one for Ctrl-F and one
for Ctrl-Alt-F. The other option of course is to change the xmodmap so
Numlock is not Meta, but that would have to be done external to your app.
Thanks for the suggestion, but I could not get it to work. How do you create
an accelerator entry for Ctrl-Alt-F, or did you mean one for Ctrl-F and one
for Alt-F?
I tried -
aTable = wxAcceleratorTable([(wxACCEL_CTRL, ord('F'), find_id),
(wxACCEL_ALT, ord('F'), find_id)])
It just combines the two behaviours reported. If NumLock is off, they both
work. If it is on, Ctrl-F does not work, Alt-F works, and 'f' by itself
works.
I also tried -
aTable = wxAcceleratorTable([(wxACCEL_CTRL|wxACCEL_ALT, ord('F'),
find_id)])
This does not work at all.
Changing xmodmap is not really an option (even if I knew how to). If I get
my app working to my satisfaction, I plan to release it as an open source
application, but it will have zero chance of success if prospective users
have to do this before they can use it.
As a last resort, I tried using F3 instead of Ctrl-F. At first, this also
did not work with NumLock on. I then found that if I have two entries in the
table - wxACCEL_NORMAL, WXK_F3 and wxACCEL_ALT, WXK_F3 - it works in all
cases. However, I feel that this is a work-around rather than a solution, as
F3 is much less intuitive than Ctrl-F for a 'find' function. A work-around
that is hidden from the user is one thing, a work-around that compromises
the user interface is quite another.
It seems to be a wxWindows problem, as no other application I have tried on
my Redhat system shows this behaviour (eg OpenOffice). Defining a ctrl-key
shortcut is standard gui practice, so this strikes me as a fairly serious
limitation of wxWindows. I really believe that wxAcceleratorTable should be
modified to ignore the Meta key state.
Apologies if this sounds harsh - it is a minor issue in the overall context
of an amazing product. However, I do feel that it should be put onto the 'to
do' list.
Frank
Frank Millman wrote:
Frank Millman wrote:
Hi all,
I am using a wxAcceleratorTable to trap Ctrl-F. I thought it was
working perfectly, on both MSW and GTK2, but I have just found a
problem with GTK2.It works if NumLock is off. If I switch it on, Ctrl-F is not
detected. Platform is Redhat 9/Python 2.2.3/wxPython 2.4.1.2u
compiled for GTK2.Robin Dunn wrote:
For some reason the NumLock is by default treated as nother
modifier key by XFree86, Meta I think. So when the key event
happens it looks like Ctrl-Meta-F instead of just Ctrl-F and so the
accelerator is not triggered.Thanks, Robin, for the explanation. However, you did not suggest a
workaround. As you may recall, I am writing an accounting
application, where a user typically ensures that NumLock is on at the
beginning of a session and leaves it on the whole time. Therefore it
is important to get a solution to this.Try making two entries in the accelerator table, one for Ctrl-F and one
for Ctrl-Alt-F. The other option of course is to change the xmodmap so
Numlock is not Meta, but that would have to be done external to your app.Thanks for the suggestion, but I could not get it to work. How do you create
an accelerator entry for Ctrl-Alt-F, or did you mean one for Ctrl-F and one
for Alt-F?I tried -
aTable = wxAcceleratorTable([(wxACCEL_CTRL, ord('F'), find_id),
(wxACCEL_ALT, ord('F'), find_id)])It just combines the two behaviours reported. If NumLock is off, they both
work. If it is on, Ctrl-F does not work, Alt-F works, and 'f' by itself
works.I also tried -
aTable = wxAcceleratorTable([(wxACCEL_CTRL|wxACCEL_ALT, ord('F'),
find_id)])This does not work at all.
I would expect this to give you an accelerator for the Ctrl-Alt-F combo.
Please enter a bug report about that.
It seems to be a wxWindows problem, as no other application I have tried on
my Redhat system shows this behaviour (eg OpenOffice). Defining a ctrl-key
shortcut is standard gui practice, so this strikes me as a fairly serious
limitation of wxWindows. I really believe that wxAcceleratorTable should be
modified to ignore the Meta key state.
Please enter a bug report about this too.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Frank Millman wrote:
>>>>Frank Millman wrote:
>>>>
>>>>
>>>>>Hi all,
>>>>>
>>>>>I am using a wxAcceleratorTable to trap Ctrl-F. I thought it was
>>>>>working perfectly, on both MSW and GTK2, but I have just found a
>>>>>problem with GTK2.
>>>>>
>>>>>It works if NumLock is off. If I switch it on, Ctrl-F is not
>>>>>detected. Platform is Redhat 9/Python 2.2.3/wxPython 2.4.1.2u
>>>>>compiled for GTK2.
>>>
>>>
>>>Robin Dunn wrote:
>>>
>>Try making two entries in the accelerator table, one for Ctrl-F and one
>>for Ctrl-Alt-F. The other option of course is to change the xmodmap so
>>Numlock is not Meta, but that would have to be done external to your
app.
>>
> I also tried -
> aTable = wxAcceleratorTable([(wxACCEL_CTRL|wxACCEL_ALT,
ord('F'),
> find_id)])
>
> This does not work at all.I would expect this to give you an accelerator for the Ctrl-Alt-F combo.
Please enter a bug report about that.
My apologies - my brain was in neutral. I tried Ctrl and Alt separately, but
not together :-[
Now that my brain is in gear again, I tried it properly, and it works as you
expected. The result is that Ctrl-F works with NumLock both off and on.
In the circumstances, I have not entered a bug report about ignoring the
Meta key state, as this solution is an effective workaround.
Many thanks
Frank