On approximately 12/8/2003 5:47 AM, came the following characters from
the keyboard of Glenn W Munroe:
Glenn,
Those accelerators are working fine and have fixed a couple of long-standing
problems (like getting a listview labeledit to work). At first, I tried to
attach them to individual controls, but found they only work at the window
level. Then, when I looked inside the Win32::GUI main window hash, I see an
'accel' key for every control. Do you know if they were ever meant to work
at control level? I take it you just use a big switch statement inside your
key handler to see which control has focus and take the appropriate action?
The code in Win32::GUI to handle -accel was actually already there... it
just had some bugs. So actually the logic flow is a bit different
than you seem to suppose.
There is no "key handler"... Windows turns key up/down events into
messages that get sent to the message queue of the currently active
process... that message queue receives not only key events but also
mouse events, click events, redraw events, drag-n-drop events, every
kind of event that you can imagine.
However, Windows guidelines tell you that there are certain APIs you
should call to preprocess the message stream before dispatching the
message to the window handler.... and they are related to keyboard
handling.... Things like TranslateAccelerator, IsDialogMessage,
TranslateMessage, and DispatchMessage (well, that isn't "before
dispatching", that IS dispatching!).
Now the way that Win32::GUI is handling accelerators is to look at an
incoming event message, obtain the handle of that message, and then
search upward in that window's parental tree until there is no more
parent, and use the accelerator table defined for that window.
I'm not exactly sure if that is a Windows-recommended technique or not,
but that is how it works at present.
It seems like it would be possible to pick up the "first defined"
accelerator table in the parental tree, rather than walking up to the
top before looking, although that would take more cycles per message to
do so.
I notice that both TranslateAccelerator and IsDialogMessage are passed
the parent window handle, rather than the one the message came in on.
Cheers,
Glenn2
PS I hope you don't mind me contacting you directly like this, but until
your fix gets into the main stream, there's not much point posting to the
users list. I'll get the hint if you're busy...
Well, I am busy... but not too busy to discuss recently release bug
fixes. Laurent has picked up my fixes in his current bug-fix branch,
but I'm not sure yet when an official bug fix release will be
produced... maybe when the rate of fix submittals slows down enough to
do so.
The benefit of communicating on-list, is that the issue is better
documented for future searches of the mailing list archives, educating
the whole community rather than just ourselves! So I hope you don't
mind my replying to the whole list, including your message.
Glenn
=====
signature-less today, it appears.
Still reinstalling software on a new hard drive.
The former signature will return, to everyone's dismay!
