Octavian Rasnita wrote:
Hi,
I have tried the test script below, and if I press enter on the text field,
the onKeyUp event is not handled at all.
If I press other keys, that event appears, but not if I press enter.
onKeyUp is handled, but I also need the onKeyUp event.
Is it a bug, or am I doing something wrong?
NO, it's expected behaviour. To understand this you need some
understanding of the internal behaviour of Win32::GUI and the Win32 API.
The following explanation omits many details, but is mostly correct.
When using the -dialoui => 1 option of a window, the message pump used
by Dialog() looks something like this:
while (GetMessage(hwnd, &msg, 0, 0)) {
if (!IsDialogmessage(hdlg, &msg)) {
TranslateMsg();
DispatchMsg();
}
}
So, every message pulled off the message queue is passed to
IsDialogMessage(). IsDialogMessage() asks the window that the message
is being sent to whether it wants the message (by sending it a
WM_GETDLGCODE message): if the window wants the message the message is
dispatched to the window, if the window doesn't want it, then
IsDialogMessage ooks to see if it is a standard keyboard navigation key,
and if so processes it itself, else it gets discarded.
Single line Edit controls (Textfields without the -multiline => 1 option
in Win32::GUI speak), always tell IsDialogMessage that they don't want
the return key, and IsDialogMessage then handles the return key as a
request to activate the default button. If you were to hook a
WM_COMMAND message with value IDOK, you'd see such a message sent to the
main window every time the return key is pressed.
One way to deal with this is to handle the WM_GETDLGCODE message (and I
posted code for hook()ing this message and decoding the parameters
passed to it to the list in the last few days).
There may be easier ways around this (it might be possible to set up the
return key as an accelerator, and within the accelerator see if your
textfield has the focus, and if so do something something?).
Regards,
Rob.
