Calling SendInput to simulate pressing down left click appears to be executed after code written below said call to SendInput is executed.
I made a listbox and I want right click to select items from the list box so I decided to make the message WM_CONTEXTMENU call SendInput to simulate a left click immediately before opening a context menu, but I believe the context menu is popping up before the left click occurs, resulting in the left click clicking the edge of the context menu (which does nothing).
Adding MessageBox(0,0,0,0); right in between the call to SendInput and the creation of the popup menu results in the left click successfully occurring and selecting an item, this is the behaviour I expected and desire. Strangely calling Sleep(1000) after the call to SendInput delays the program but doesn't cause the SendInput to behave as expected.
EDIT: Yes I know one solution to my problem is to select it using LB_SETSEL, but I'm partially doing this for learning purposes and if I run into a similar problem using SendInput I want to know how to solve it, so please help me resolve this specific bug.
SendInput() merely injects keystrokes into the keyboard's input buffer and then exits immediately, letting your app do other things while Windows handles the keystrokes in the background as if the user had typed them manually. That is not the solution to your problem.
In your WM_CONTEXTMENU handler, simply send a LB_SETCURSEL message (for a single-select ListBox) or a LB_SETSEL message (for a multi-select ListBox) directly to the ListBox's HWND to select the desired list item(s) before then displaying your popup menu.
Related
I need to make a custom hotkey for the alt-tab function. I'm doing this with SendInput by sending the corresponding keys, and it works fine.
However, if a hotkey already includes the alt key, the program only needs to press and release tab; but doing so causes the alt-tab menu to get stuck on screen even, and the only way to make it go away is to close my program. How could that possibly happen, and what does closing my program have to do with the menu disappearing?
On the other hand, sending (alt down)(tab down)(tab up)(alt up) keys regardless of whether alt is already down works in all cases, but I can't rely on this behavior for other reasons.
I'm using WinXP if that helps, I haven't tried it on the Win7 computer yet.
Had a similar problem caused by doing PostMessage WM_KEYDOWN, VK_TAB, in an event triggered by operator clicking ALT-N to cancel an action. The ALT key was thus still down when the tab was sent. Since our code never sends a WM_KEYUP, it must have confused Win XP. Left the alt-tab menu on the screen until the application exited.
I don't know if this related, but Alt+Ctrl+Tab causes the menu to stuck, just like if Alt would stick when press Alt+Tab. So may be you are sending Ctrl signal somehow.
I am currently developing a user interface DLL that uses the WIN32 API. The DLL must work for numerous platforms, XP, WIN CE, etc. I have managed to incorporate docking, anchoring and so on but appear to have a problem regarding owner-drawn buttons. I can draw the button's correct state, focus, clicked, default. However, I cannot receive key notifications. I specifically want to perform a click operation on a button that currently has focus, should the user press enter.
Note that I am using a windows message loop rather than a dialog message loop. I use windows hooks to hook into the window creation and set the user data to 'point' to my control instance. If I test for WM_KEYDOWN in the main message loop I can get a handle to my button control instance and could forward the message to the relevant control. Unfortunately, I am dealing with a lot of legacy code and this may not be an ideal solution.
So, my question is what is the best way forward. Is subclassing the button control's window procedure a viable option or is there an easier way?
Many thanks in advance.
The comments above are correct. The button with focus should be getting the key messages. But buttons don't (by themselves) respond to Enter--they respond to Space. It sounds like what you're missing is the typical dialog keyboard navigation, like Tab key moving the focus and Enter activating the "default" button.
If you've got a typical Windows message pump, and you want the keyboard behavior normally associated with dialogs, then you need to use the IsDialogMessage API in your message loop. This means your window is essentially a "modeless dialog".
Looks like standard window proc subclassing should do the trick. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms633591(v=vs.85).aspx for details.
I want to change the default behaviour of a combobox (c++, win32 api). I make the combobox drop down when something is entered in its edit control I want to avoid the default behaviour that the combobox searches for the first match in the list, selects it, and enters the selected string into the edit control. Can I suppress this behaviour by catching the respective (LB_SETCURSEL etc.) messages out of the message queue myself with GetMessage()?
Does anyone habe a different idea of how to do it?
Greets
Michbeck
You likely want to implement Window subclassing. This allows you to insert your own WndProc function into the combobox control that gets called before the control's own WndProc is called. You can filter out (and drop) window messages you don't want the control to get.
I'm not booted into my windows partition right now to run Spy++ on a combobox to see what messages it actually receives. My guess is that you want to filter out WM_CHAR from being received by the combobox.
I'm trying to understand the listbox notification LBN_SELCANCEL. MSDN says "Notifies the application that the user has canceled the selection in a list box." OK, but how exactly does a user "cancel the notification"? I've got LBS_NOTIFY set, and I've tried selecting another item, clicking outside the listbox, clicking another window, and none of these trigger LBN_SELCANCEL.
Anyone know what specifically triggers this notification?
I believe LBN_SELCANCEL only applies to ComboBox controls because they also use lists.
It should be called when you open the drop down hover over an element then press ESC.
How would one prevent the little dotted square that appears on a button when it has the keyboard focus in a dialog. (w/ apologies for the technical jargon). At one point I hacked together a solution by subclassing a button WindowProc and subverting some windows messages, but wanted to know the correct way.
There's actually a problem with another control in the dialog also involving the keyboard. This other control is actually also a button, but being used as a group box or panel, not as a functioning button. But when I hit the tab key in the dialog, this group box "button" comes to the foreground obscuring the static controls on top of it, so I wanted to prevent that.
For both of the above, I tried turning off WS_TABSTOP - didn't help.)
Both of my problems mentioned above were solved by subclassing the WndProcs and returning 0 in response to message 0x128 and discarding it. Even Spy++ could not identify this message 0x128, and I don't have it in any header. But its sent to every control in the dialog the first time tab is hit in the dialog.
(I did try BN_SETFOCUS as described above and also WM_SETFOCUS but it didn't help.)
So if anyone knows where to find what windows message 0x128 is...
The correct way is to write your own button control instead of using the default Windows one.
Alternatively, you can prevent if from ever getting keyboard focus.