I got a WM_COMMAND in a button event by Spy++, It looks like:
<000116> 001B0A02 S WM_NOTIFY idCtrl:133978 pnmh:0019F9A0
<000117> 001B0A02 R WM_NOTIFY
<000118> 001B0A02 S WM_COMMAND wNotifyCode:0000 wID:2 hwndCtl:00020B5A
<000119> 001B0A02 R WM_COMMAND
<000120> 001B0A02 S WM_NOTIFY idCtrl:133978 pnmh:0019F9BC
<000121> 001B0A02 R WM_NOTIFY
Then I tried to redo WM_COMMAND by SendMessage:
Nothing happened. I used the AHK script to be sure, same result.
When I used SendMessage(), Spy++ got this:
<000423> 001B0A02 S WM_COMMAND wNotifyCode:0000 wID:2 hwndCtl:00000014
<000424> 001B0A02 R WM_COMMAND
I also let the lParam = 0, then it worked but not as I expected, another Menu item opened.
<000001> 001B0A02 S WM_COMMAND wNotifyCode:0 (sent from a menu) wID:2
So how can I do this?
To emulate the WM_COMMAND for a button click, you need to send the ID of your button and the BN_CLICKED notification code (combined) as the wParam argument to SendMessage(), and the handle (HWND) of the button as the lParam.
If hDlg is the handle of your dialog window, and IDC_MYBUTTON is the resource ID of your button, the call would be like this:
SendMessage(hDlg, WM_COMMAND, MAKEWPARAM(IDC_MYBUTTON, BN_CLICKED), (LPARAM)GetDlgItem(hDlg, IDC_MYBUTTON));
As it happens, the BN_CLICKED notification code has a value of 0, so the wParam value will be just the control ID; this appears to be 2 in your case – the value used by Windows for the "Cancel" button. The problem, in your code, seems to be an invalid window handle for the lParam argument.
Related
My VB6 application is usually hidden and has a tray icon. It currently handles a user-defined callback as per this code:
Public Const WM_USER = &H400
Public Const TRAY_CALLBACK = (WM_USER + 1001&)
With GTStruct
.uID = mId
.hwnd = frm.hwnd
.hIcon = frm.Icon.Handle
.UFlags = NIF_ICON Or NIF_MESSAGE
.uCallbackMessage = TRAY_CALLBACK
.cbSize = Len(GTStruct)
End With
Shell_NotifyIcon NIM_ADD, GTStruct
A WindowProc handles TRAY_CALLBACK and the click message:
Const WM_NCDESTROY = &H82
Const WM_CLOSE = &H10
' If we're being destroyed, remove the tray icon
' and restore the original WindowProc.
If Msg = WM_NCDESTROY Or Msg = WM_CLOSE Then
RemoveFromTray
ElseIf Msg = TRAY_CALLBACK Then
' The user clicked on the tray icon.
' Look for click events.
If lParam = WM_RBUTTONUP Then
' On right click, show the menu.
SetForegroundWindow TheForm.hwnd
TheForm.PopupMenu TheMenu
If Not (TheForm Is Nothing) Then
PostMessage TheForm.hwnd, WM_NULL, ByVal 0&, ByVal 0&
End If
Exit Function
End If
End If
As it is, the application works and right-clickign the icon brings up the menu. I want to handle the mouse_move message in addition to this existing callback message so I changed the callback to this:
.uCallbackMessage = TRAY_CALLBACK Or WM_MOUSEMOVE
However, this ignores the mousemove message. If I use :
.uCallbackMessage = WM_MOUSEMOVE
The mouse_move message works and Form_MouseMove is called properly but then the menu stops working.
The question
How can I specify multiple callbacks in order to handle both the mouse move and the mouse click?
You can only have one callback message per icon; in your case, this is TRAY_CALLBACK. When you receive this message the lParam value indicates which mouse message triggered your callback.
In your example code you're already comparing lParam against WM_RBUTTONUP. You just need to add an additional check against WM_MOUSEMOVE.
I'm developing a Word addin for MS Word on Windows, and this addin has as 'advanced task pane' showing and docking on the left side of the Word document window (it's treeview(outline) showing a list of Word documents for fast editing multiple documents in a project).
My question is, the Word document window responds to mouse wheel message only when it's focused, but I want to be able to scroll the document with mouse wheel whenever the mouse cursor is hovering on it even the Word document window doesn't have a input focus.
Any hints in this particular case? Thank you!
Not quite sure it will work, but I'd try the following:
Implement a global low-level mouse hook using the SetWindowsHookEx function.
In the hook procedure, which should be called on mouse wheel scroll events, check if the window under mouse cursor is the Word document window. If so, set a shared flag indicating the needed scroll action.
Don't send WM_VSCROLL directly from the hook procedure! This procedure has to be really fast and simple.
Now, in your add-in's message loop check the flag and if it is set, send WM_VSCROLL to the Word document window.
Perhaps you could make use of the SetCapture(hWnd) Windows API function. This will cause all mouse events to go to your hWnd instead of whatever hWnd might normally expect to receive them. If you capture when the mouse enters the Word document window, and ReleaseCapture() when the mouse leaves or Word gains focus, it should work alright.
Disclaimer: I've used mouse capturing in C# before, but I've never done it in C++. I don't know if it behaves exactly the same way.
Try the following , this might help you.
1) Handle WM_MOUSEHOVER message.
2) In the handler , use SendMessage, with WM_VSCROLL as the message parameter .
Using Spy++ I saw that the window that gets the messages is of the class _Wwg (At least 2003 is) and it is responding to the WM_MOUSEWHEEL message. So you would send that window a WM_MOUSEWHELL message when you want it to scroll.
I've got the C++ code snipped below from a comment in https://msdn.microsoft.com/en-us/library/windows/desktop/ms645617(v=vs.85).aspx
And I used it (and variations on it) successfully.
The user who wrote it claims it was inspired by a ms recommendation on a Windows Vista best practices guide, to forward the mouse wheel event to whatever window is hovered by the mouse cursor. The virtue of his/her implementation is that it's completely unintrusive, you just drop it and it set the hooks, referencing your main thread. It avoids forwarding the event to windows belonging to other processes, but perhaps that could actually be a good thing.
namespace {
LRESULT CALLBACK mouseInputHook(int nCode, WPARAM wParam, LPARAM lParam) {
//"if nCode is less than zero, the hook procedure must pass the message to the CallNextHookEx function
//without further processing and should return the value returned by CallNextHookEx"
if (nCode >= 0) {
MSG& msgInfo = *reinterpret_cast<MSG*>(lParam);
if (msgInfo.message == WM_MOUSEWHEEL ||
msgInfo.message == WM_MOUSEHWHEEL) {
POINT pt = {};
pt.x = ((int)(short)LOWORD(msgInfo.lParam)); //yes, there's also msgInfo.pt, but let's not take chances
pt.y = ((int)(short)HIWORD(msgInfo.lParam)); //
//visible child window directly under cursor; attention: not necessarily from our process!
//http://blogs.msdn.com/b/oldnewthing/archive/2010/12/30/10110077.aspx
if (HWND hWin = ::WindowFromPoint(pt))
if (msgInfo.hwnd != hWin && ::GetCapture() == nullptr) {
DWORD winProcessId = 0;
::GetWindowThreadProcessId(//no-fail!
hWin, //_In_ HWND hWnd,
&winProcessId); //_Out_opt_ LPDWORD lpdwProcessId
if (winProcessId == ::GetCurrentProcessId()) //no-fail!
msgInfo.hwnd = hWin; //it would be a bug to set handle from another process here
}
}
}
return ::CallNextHookEx(nullptr, nCode, wParam, lParam);
}
struct Dummy {
Dummy() {
hHook = ::SetWindowsHookEx(WH_GETMESSAGE, //__in int idHook,
mouseInputHook, //__in HOOKPROC lpfn,
nullptr, //__in HINSTANCE hMod,
::GetCurrentThreadId()); //__in DWORD dwThreadId
assert(hHook);
}
~Dummy() {
if (hHook)
::UnhookWindowsHookEx(hHook);
}
private:
HHOOK hHook;
} dummy;
}
Below is my code to generate left click using win32 api. The problem is that it gets stuck and does not return to main. When i press Ctrl+c, then it returns to main. BUT when I call it twice, to simulate double click then it is fine. Is there anything wrong with this code?
Thank you.
void LeftClick(void)
{
INPUT Input={0};
// left down
Input.type = INPUT_MOUSE; /*The event is a mouse event. Use the mi structure of the union.*/
Input.mi.dwFlags = MOUSEEVENTF_LEFTDOWN;
SendInput(1,&Input,sizeof(INPUT));
// left up
ZeroMemory(&Input,sizeof(INPUT));
Input.type = INPUT_MOUSE;
Input.mi.dwFlags = MOUSEEVENTF_LEFTUP;
SendInput(1,&Input,sizeof(INPUT));
}
If you're not committed to using SendInput, I've had success in the past using SendMessage on the desired hWnd with WM_LBUTTONDOWN then again with WM_LBUTTONUP.
Most buttons also simulate a click with keyboard entry. You can use SendMessage to your desired hWnd with WM_KEYDOWN and wParam VK_SPACE, then WM_KEYUP with VK_SPACE to complete the space bar keypress simulation.
I am trying to send some simple mouse down/up messages to Windows Calculator using SendMessage. I have been able to press the buttons by sending the messages to the buttons directly. However, I have not been able to successfully send the same messages to the main calculator window handle. Given that hWnd is the window handle to calculator, this is my code.
IntPtr fiveKey = FindWindowEx(hWnd, IntPtr.Zero, "Button", "5");
int x = 5; // X coordinate of the click
int y = 5; // Y coordinate of the click
IntPtr lParam = (IntPtr)((y << 16) | x); // The coordinates
IntPtr wParam = IntPtr.Zero; // Additional parameters for the click (e.g. Ctrl)
const uint downCode = 0x201; // Left click down code
const uint upCode = 0x202; // Left click up code
SendMessage(fiveKey, downCode, wParam, lParam); // Mouse button down
SendMessage(fiveKey, upCode, wParam, lParam); // Mouse button up
Can anyone explain to me why sending the messages to hWnd instead of fiveKey with the x/y offsets changed to the position of the "5" key does not work? I would like to eventually use this code to simulate mouse clicks on a different application that doesn't have buttons like calculator.
I'm not sure I follow you. Are you trying to send WM_LBUTTONDOWN to the main window with the coordinates of where the 5 button is, with the hopes that the 5 button will get "clicked"? If so, that's just not going to work. WM_LBUTTONDOWN is only ever sent to the window under the mouse cursor. In theory the main window could handle WM_LBUTTONDOWN and see if any of its child windows are at that location, but nobody does that because that's not how WM_LBUTTONDOWN is designed to work.
I have added a keyboard hook for a dialog that I don't control (it runs its own DialogProc Function in a library with closed source). I'm able to capture the key strokes, but the key stroke is always sent the dialog. This causes error beeps as well as some weird behavior.
Installing the hook:
hKeyHook=SetWindowsHookEx(WH_KEYBOARD, KeyHookProc, hInst, GetCurrentThreadId());
The hook function:
LRESULT CALLBACK KeyHookProc(int code, WPARAM wParam, LPARAM lParam)
{
if(!(lParam & 0x80000000))
{
if(wParam == VK_mykey)
{
// Do my stuff
return 0; // Don't continue the hook chain
}
}
// Continue with next hook
return CallNextHookEx(hKeyHook, code, wParam, lParam);
}
Releasing the hook:
UnhookWindowsHookEx(hKeyHook);
Is there a way to stop the key stroke from being sent to the control that has focus in the dialog?
You could subclass the control in question by replacing its GWLP_WNDPROC (See the remarks section of this page) value. The basic concept is that you filter out the WM_KEY* messages, then pass the rest to the original WndProc.
This
if(!(lParam & 0x80000000))
is true when the key is pressed. When it's released you do nothing.
KeyHookProc is called when the keys are held down or when they are released.
Hmm. First point are you sure that you wish to use your own process thread id here. Is the dialog definitely under your process thread?