SetWindowsHookEx for WH_MOUSE
// here I put WH_MOUSE instead of WH_MOUSE_LL
hMouseHook = SetWindowsHookEx( WH_MOUSE_LL, mouseProc, hInstance, NULL );
Fourth param must also be changed to GetCurrentThreadId() to make it local.
SetWindowsHookEx WH_MOUSE_LL Hook only takes 1 mouse movement
I have a breakpoint set
That's enough to explain the problem. The debugger will break of course. Which prevents further mouse messages from being delivered to the window with the focus. Windows puts up with that for 5 seconds, then unceremoniously disables your hook because it thinks your code is broken.
The timeout is configurable, you can use Regedit.exe to set the HKEY_CURRENT_USER\Control Panel\Desktop\LowLevelHooksTimeout value. Not present by default, add the DWORD value first. The unit is milliseconds.
Blocking windows mouse click using SetWindowsHookEx()
The reason you are supposed to call CallNextHookEx during your hook routine is so that the message can be passed on to any other hooks that might be installed. Failing to do so does not prevent the message from being seen by the application that received it.
The documentation for WM_NULL explains how to block the message:
For example, if an application has installed a WH_GETMESSAGE hook and wants to prevent a message from being processed, the GetMsgProc callback function can change the message number to WM_NULL so the recipient will ignore it.
The corrected code should therefore look something like this:
extern "C" __declspec(dllexport) LRESULT __stdcall meconnect(int code, WPARAM wParam, LPARAM lParam) {
if (code >= 0) {
LPMSG msg = (LPMSG)lParam;
if (msg->message == WM_LBUTTONDOWN) {
OutputDebugString(L"Mouse down event happened \n");
msg->message = WM_NULL;
return false;
}
}
return(CallNextHookEx(NULL, code, wParam, lParam));
}
However, this may cause inconsistent behaviour if other hooks are present, because whether another hook sees WM_LBUTTONDOWN or WM_NULL will depend on the order of the hook chain, which is unpredictable. It might be preferable to try something like this:
extern "C" __declspec(dllexport) LRESULT __stdcall meconnect(int code, WPARAM wParam, LPARAM lParam) {
if (code >= 0) {
LPMSG msg = (LPMSG)lParam;
int result = CallNextHookEx(NULL, code, wParam, lParam);
if (msg->message == WM_LBUTTONDOWN) {
OutputDebugString(L"Mouse down event happened \n");
msg->message = WM_NULL;
}
return result;
}
return(CallNextHookEx(NULL, code, wParam, lParam));
}
setting mouse hooks in C# with setwindowshookex: wparam and lparam always return constant
According to MSDN your lParam is a pointer to MOUSEHOOKSTRUCT which can be easily converted from pointer to structure using this technique.
Working code would look like this:
[StructLayout(LayoutKind.Sequential)]
struct Point
{
public int X;
public int Y;
}
[StructLayout(LayoutKind.Sequential)]
struct MOUSEHOOKSTRUCT
{
public Point pt;
public IntPtr hwnd;
public uint wHitTestCode;
public IntPtr dwExtraInfo;
}
private int HookCallback(int nCode, IntPtr wParam, IntPtr lParam)
{
if (MouseMessages.WM_LBUTTONDOWN == (MouseMessages)wParam)
{
// Do something.
var mhs = Marshal.PtrToStructure<MOUSEHOOKSTRUCT>(lParam);
Console.WriteLine($"point: {mhs.pt.X} {mhs.pt.Y}");
}
return CallNextHookEx(this.hookID, nCode, wParam, lParam);
}
SetWindowsHookEx with WH_MOUSE not capturing mouse moves over HTCAPTION area
I figured it out :
MouseHookProc the mouseproc given to SetWindowsHookEx receive all the events of the mouse that mean I have to test that wParam is equal to WM_MOUSE or WM_NCMOUSEMOVE. When the cursor is over a client area WM_MOUSE is received and when it is over a nonclient area WM_NCMOUSEMOVE is fired (like in a normal message proc ).
LRESULT CALLBACK MouseHookProc(int nCode, WORD wParam, DWORD lParam)
{
if(nCode>=0 && (wParam==WM_MOUSEMOVE || wParam==WM_NCMOUSEMOVE))
{
if(!hwnd)
hwnd=FindWindow(0, "MyWindow");
MSLLHOOKSTRUCT *mhs=(MSLLHOOKSTRUCT*)lParam;
PostMessage(hwnd, WM_MOUSEHOOK, wParam, 0);
}
return CallNextHookEx(hHook,nCode,wParam,lParam);
}
I thought that WM_MOUSE was some sort of corresponding value but not the real mouse message, but it is.
SetWindowsHookEx, identifying the windows dialog where the mouse is pointing
For those who are interested, I would like to post the answer that I was able to implement. Basically , instead of listening to WH_GETMESSAGE, I changed the hook chain to WH_MSGFILTER. Reason because, it allows me to find the menu item id when I move the mouse over menu item and when the button up event happens, I can check the menu item id and disable mouse click by changing the message to WM_NULL. following is the working code sample. It also enable u to block the event if user is navigat
dll code
#include "stdafx.h"
#include <stdio.h>
#include <windows.h>
#include <Winuser.h>
#include <Lmcons.h>
#include "nxlrunner.h"
WORD wMenuItemID;
INT APIENTRY DllMain(HMODULE hDLL, DWORD Reason, LPVOID Reserved) {
switch (Reason) {
case DLL_PROCESS_ATTACH:
OutputDebugString(L"DLL attach function called11.\n");
break;
case DLL_PROCESS_DETACH:
OutputDebugString(L"DLL detach function called.\n");
break;
case DLL_THREAD_ATTACH:
OutputDebugString(L"DLL thread attach function called.\n");
break;
case DLL_THREAD_DETACH:
OutputDebugString(L"DLL thread detach function called.\n");
break;
}
return TRUE;
}
extern "C" __declspec(dllexport) LRESULT __stdcall meconnect(int code, WPARAM wParam, LPARAM lParam) {
switch (code)
{
case MSGF_MENU: // message is for a menu
{
MSG* pMSG = (MSG*)lParam;
switch (pMSG->message)
{
case WM_MENUSELECT:
{
wMenuItemID = LOWORD(pMSG->wParam);
break;
}
case WM_LBUTTONDOWN:
{
break;
}
case WM_LBUTTONUP:
{
if (wMenuItemID == 10353){
wchar_t usernamew[UNLEN];
DWORD username_len = UNLEN + 1;
GetUserNameW(usernamew, &username_len);
MessageBoxW(NULL, usernamew, L"Title", MB_OK);
pMSG->message = WM_NULL;
}
break;
}
case WM_LBUTTONDBLCLK:
{
if (wMenuItemID == 10353){
pMSG->message = WM_NULL;
}
break;
}
case WM_KEYDOWN:
{
switch (pMSG->wParam)
{
case VK_RETURN:
{
if (wMenuItemID == 10353){
MessageBoxW(NULL, L"Message to user", L"Title.", MB_OK);
pMSG->message = WM_NULL;
}
break;
}
}
break;
}
case WM_KEYUP:
{
switch (pMSG->wParam)
{
case VK_RETURN:
{
if (wMenuItemID == 10353){
MessageBoxW(NULL, L"Message to user", L"Title", MB_OK);
pMSG->message = WM_NULL;
}
break;
}
}
break;
}
}
break;
}
}
return false;
}
windows hooking
system message hooks
Call MSG Filter function
msg structure
sample code
keyboard codes
sample code from internet
SetWindowsHookEx WH_JOURNALRECORD Blocks Mouse Clicks + Keystrokes
After many hours of troubleshooting, I noticed that the hook installs and runs as expected if I create a new user account on Windows and run it from there.
I dumped all running processes and services on my new test account, as well as on my main account, and examined those that were only present on my main account.
I located a service (Alienware Command Center) that runs as part of software that allows me to customize my mouse and keyboard. When the service and corresponding processes(s) are killed, Journal hooks work as expected.
Something inside of that service is for whatever reason interfering with the hook.
Related Topics
Detect Gcc Compile-Time Flags of a Binary
Why Are Forward Declarations Necessary
Is There a Limit of Stack Size of a Process in Linux
Convert a Unicode String in C++ to Upper Case
Gcc - How to Create a Mapfile of the Object File
What Is the Meaning of Auto When Using C++ Trailing Return Type
Why Is the Size of Array as a Constant Variable Not Allowed in C But Allowed in C++
Create a Reverse Linkedlist in C++ from a Given Linkedlist
Why Do String Literals (Char*) in C++ Have to Be Constants
_Iterator_Debug_Level Value '0' Doesn't Match Value '2'
Cast Vector<T> to Vector<Const T>