I have a dialog with no controls derived from CDialogEx. I receive OnKeyDown() messages but never receive a OnChar() ? I even tried overriding PreTranslateMessage() and just returning 0 when receiving a WM_KEYDOWN message as a test, still no OnChar()? What am I missing so I don't have to use ToUnicode() or ToAscii() in the OnKeyDown() routine?
TIA!
Related
My goal is to disable some tool-tip-like thing in window of another process. My thoughts are to block WM_MOUSEMOVE if the coordinates of mouse movement is in certain rectangle of the window.
I can use SetWindowsHookEx to receive that messages (WH_CALLWNDPROC and WH_GETMESSAGE), but it doesn't allow to block them. I can return 1 instead of calling CallNextHookEx, but it doesn't prevent WndProc of window to receive the message. However, this approach works for blocking events in MOUSE_LL/KEYBOARD_LL.
SetWindowsHookEx is also not good, because it installs hook to all windows across the system.
How I can prevent window of another process from receiving certain windows messages?
The WH_GETMESSAGE message hook doesn't let you "block" or cancel the message but you can modify it. So simply change lpMsg->message to WM_NULL to prevent the mouse move message from being processed by the target window.
I have a TreeView that allows users to change the labels. To do this I have a handler for the TVN_ENDLABELEDIT notification that reads the TVITEM from the NMTVDISPINFO structure and sends the TVM_SETITEM message.
All of this works fine EXCEPT in one particular case: when for the sake of debbuging I interrupt the execution of the handler BEFORE returning with 0 from the notification.
What happens in this case is that if another notification arrives before the handler returns with 0, i.e., before I'm done debbuging it, the TreeView will crash the application because it will call a rutine at a null pointer.
This means that the TreeView somehow trusts the handler from finishing before other event gets processed.
Has anyone experienced this kind of behavior? I think the OS should be a little bit more robust; shouldn't it?
When I create a dialog using DialogBox, it won't close unless I handle WM_CLOSE in my own DLGPROC function and call EndDialog.
I know that this is by design, but I'm interested why was it chosen for WM_CLOSE not to be handled automatically by DefDlgProc? Are there any good reasons for that?
Ask yourself this:
What would the default handling of WM_CLOSE be? Calling EndDialog? I think EndDialog would only work in very rare situations.
Other suggestions:
validating user input in the dialog, showing errors if input is out-of-range or otherwise not valid, not ending the dialog
closing child windows, releasing resources/memory that child windows of the dialog are using, releasing COM-Objects, basically: cleaning up first and then end the dialog.
When a modal dialog box is present, messages sent to the main window using PostMessage do not go through that window's message loop. In fact, no message go through the main window's message loop while the modal dialog is present. They do make it to the main window's WndProc presumably through some message loop in the dialog handling.
Is this normal or am I doing something bizarre?
This is normal, the dialog box becomes modal by pumping its own message loop. This should not be a problem, DispatchMessage still delivers the message to the window procedure. Make sure you post with a valid window handle. Otherwise also the reason that PostThreadMessage() is a guaranteed fail whale if the thread creates any windows. Like MessageBox().
I am looking for a solution to programmatically hold a keyboard key down during some time (I don't know how many time).
I think that if I send a WM_KEYDOWN message the key will be held down until WM_KEYUP is send, but I am not sure.
I would test it. But I need to go and I don't have much time. I want to see if someone already tested this.
Here is an other question I posted, related to this one.
I want to make a virtual keyboard. Do I need to send WM_KEYDOWN to the current active window or HWND_BROADCAST?
No, because If you examine the messages sent when using the keyboard, you'll see that the message are as follow:
WM_KEYDOWN
WM_KEYPRESS
WM_KEYUP
The WM_KEYPRESS message is sent every couple of ticks (depending on the keyboard configuration).
WM_KEYDOWN and WM_KEYUP are messages generated by the system - it's dependent on how the application interprets those messages. Synthesizing these messages will have no effect on the actual keyboard state.
If you want to simulate keyboard input, use the SendInput API.