I'm trying to create macro application that will start running certain operations when key is pressed (system wide shortcut). I did created Windows Form Application with Visual Studio 2012. When form is loaded keyboard hook is installed:
HookHandle = SetWindowsHookEx( WH_KEYBOARD_LL, (HOOKPROC)keyboardHookHandler, GetModuleHandle(NULL), NULL);
if( HookHandle == 0){
MessageBox::Show("Error setting hook!");
}
My hook callback function is:
public: static LRESULT CALLBACK keyboardHookHandler( int code, WPARAM wParam, LPARAM lParam ) {
if(code>=0 && wParam == WM_KEYDOWN){
MessageBox::Show("Key Down");
}
return CallNextHookEx( HookHandle, code, wParam, lParam);
}
When I do compile application and run it message box is never shown. More to say I know this call back function is fired but wParam always contains value 45 (I did checked and none of those WM constants that should be returned has value 45). Also after few key events application crashes.
What is the reason why this code doesn't work like it should to?
Update:
I did removed cast to HOOKPROC and changed it to delegated procedure:
private:
delegate LRESULT CALLBACK HOOKPROC( int code, WPARAM wParam, LPARAM lParam );
HOOKPROC^ keyboardHookProcedure;
And hook setting to:
keyboardHookProcedure = gcnew HOOKPROC(this, &MyForm::keyboardHookHandler);
HookHandle = SetWindowsHookEx( WH_KEYBOARD_LL, keyboardHookProcedure, GetModuleHandle(NULL), NULL);
But now I have this problem:
error C2664: 'SetWindowsHookExW' : cannot convert parameter 2 from 'WindowsFormTest::MyForm::HOOKPROC ^' to 'HOOKPROC'
If you're trying to catch a unique key combination globally, it might be simpler to use RegisterHotKey. It defines a system-wide hot key with no need for hooks or anything special. It is going to override the foreground process handling, so this won't be ideal if you're trying to register a common key combo.
Related
I am using the Windows API on Windows7 with Visual Studio 2019.
I'm trying to set a low level keyboard hook and read the key input to the console, to do so I use the function: HHOOK SetWindowsHookExA( [in] int idHook, [in] HOOKPROC lpfn, [in] HINSTANCE hmod, [in] DWORD dwThreadId )
with the argument: WH_KEYBOARD_LL so I can monitor keyboard events.
This is my main function:
int main()
{
...
HHOOK keyBoardHook = SetWindowsHookExW(WH_KEYBOARD_LL, keyboardHook, NULL, 0);
MSG message;
while (true)
{
while(PeekMessage(&message, NULL, 0, 0, PM_REMOVE) != 0)
{
DispatchMessage(&message);
}
}
...
UnhookWindowsHookEx(keyBoardHook);
return 0;
}
And this is the callback implementation:
LRESULT CALLBACK keyboardHook(int nCode, WPARAM wParam, LPARAM lParam)
{
if (nCode == HC_ACTION)
{
KBDLLHOOKSTRUCT* keyData = (KBDLLHOOKSTRUCT*)lParam;
if (wParam == WM_KEYDOWN || wParam == WM_SYSKEYDOWN)
{
fileHandler.addStr(keyHandler.translate(keyData,true,topWindowThreadId));
}
else if (wParam == WM_KEYUP || wParam == WM_SYSKEYUP)
{
fileHandler.addStr(keyHandler.translate(keyData,false,topWindowThreadId));
}
}
return CallNextHookEx(NULL, nCode, wParam, lParam);
}
How both variables work is not the issue here but just know that
in the callback keyHandler translates the message and fileHandler prints the result to a file.
Here comes the issue. The callback receives:
a key down event when I press a key
a key up event when I release
a repeated key down event when I hold a key
a control key up event VK_LCONTROL when focused window changes
Why does that happen ? This behavior is never mentioned in the MSDN documentation as far as I know. If I switch from console window or any window to any other window this event is generated and a [left control up] message is printed by my keyHandler !
Now to make sure it's not a problem with my code I changed the Callback to this:
LRESULT CALLBACK keyboardHook(int nCode, WPARAM wParam, LPARAM lParam)
{
if (nCode == HC_ACTION)
{
KBDLLHOOKSTRUCT* keyData = (KBDLLHOOKSTRUCT*)lParam;
if (keyData->vkCode == VK_LCONTROL)
{
printf("CTRL");
}
}
return CallNextHookEx(NULL, nCode, wParam, lParam);
}
And still CTRL is printed to the consol whenever I change the focused window, Note that only VK_LCONTROL is generated and wParam is always WM_KEYUP
This is not supposed to happen!
I tried analyzing and modifying my code, tried removing everything from the main function until it looked just like in the example above even rebooted the computer to check if it's an internal issue, nothing helps. and when searching the web for a similar post with a similar issue I found absolutely none, which makes it even more confusing.
Update
I tried compiling someone else's keyboard-hook related code from GitHub, same issue.. is this normal ? Why is it not documented ?
According to the description of the SetWindowsHookExA in the official Microsoft documentation.
The global hooks are a shared resource, and installing one affects all applications in the same desktop as the calling thread. All global hook functions must be in libraries. Global hooks should be restricted to special-purpose applications or to use as a development aid during application debugging. Libraries that no longer need a hook should remove its hook procedure.
HHOOK SetWindowsHookExA(
[in] int idHook,
[in] HOOKPROC lpfn,
[in] HINSTANCE hmod,
[in] DWORD dwThreadId
);
For desktop apps, if this parameter(dwThreadId) is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread. That's why after you changed the focused window, CTRL still printed to the console. So it is recommended that you use hook in DLL.
So I am trying to make a message box appear when a user presses a button on his/her keyboard using Hooks.
The hook is getting installed correctly because there are no errors, but it seems like the KeyboardProc Callback function is not getting called because the message box that is supposed to show up when it is called never shows up.
There are no errors btw that show up and I am programming this in a desktop app.
Here is the code regarding the hook and the callback function:
LRESULT CALLBACK KeyboardProc(
int nCode, WPARAM keyState, LPARAM keyInfo) {
LRESULT reValue = 0;
MessageBox(hWnd, L"Testing", L"Test", MB_OK);//This is the msg box that isnt showing up
if (nCode < 0) {
reValue = CallNextHookEx(keyboardHook, nCode, keyState, keyInfo);
}
return reValue;
};
keyboardHook = SetWindowsHookEx(WH_KEYBOARD, (HOOKPROC)KeyboardProc, hInstance, 0);
You need to run a message loop to process the calls. From the remakrs on the KeyboardProc callback function description: "The call is made by sending a message to the thread that installed the hook. Therefore, the thread that installed the hook must have a message loop."
I am having issues with creating a modeless dialog from a DLL file. My dialog has nothing special on it, just an OK button and an edit box. I have looked at this Microsoft KB Article (http://support.microsoft.com/kb/233263) and have implemented its solution to create a window hook to grab and process messages.
The method provided by Microsoft solves the tab key problem, however, it creates another problem. When I type into the edit box on the dialog, whatever I press is duplicated 4 times. For example, if I press 'a' on the keyboard, 'aaaa' will show up in the edit box.
If I disable the Window Hook, then the edit box works correctly and only displays one 'a'.
What do I need to do to the Window Hook procedure to solve this problem?
Any help is greatly appreciated.
- - EDIT - -
As per request, my Window Hook Procedure Code: (It's the same as the KB article)
LRESULT FAR PASCAL GetMsgProc(int nCode, WPARAM wParam, LPARAM lParam) {
LPMSG lpMsg = (LPMSG) lParam;
if (nCode >= 0 && PM_REMOVE == wParam) {
// Don't translate non-input events.
if ((lpMsg->message >= WM_KEYFIRST && lpMsg->message <= WM_KEYLAST)) {
if (IsDialogMessage(hwndDllDlg, lpMsg)) {
// The value returned from this hookproc is ignored,
// and it cannot be used to tell Windows the message has been handled.
// To avoid further processing, convert the message to WM_NULL
// before returning.
lpMsg->message = WM_NULL;
lpMsg->lParam = 0;
lpMsg->wParam = 0;
}
}
}
return CallNextHookEx(NULL, nCode, wParam, lParam);
}
My Dialog Callback Procedure:
BOOL CALLBACK DllDlgProc(HWND hwndDlg, UINT uMsg, WPARAM wParam, LPARAM lParam) {
switch (uMsg) {
case WM_INITDIALOG:
hHook = SetWindowsHookEx(WH_GETMESSAGE, GetMsgProc, NULL, GetCurrentThreadId());
return TRUE;
case WM_COMMAND:
if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL) {
DestroyWindow(hwndDlg);
hwndDllDlg = NULL;
}
return TRUE;
case WM_DESTROY:
UnhookWindowsHookEx(hHook);
return FALSE;
}
return FALSE;
}
}
Both hHook and hwndDllDlg are defined as HHOOK and HWND respectively.
HHOOK hHook;
HWND hwndDllDlg = CreateDialog(0, MAKEINTRESOURCE(DLG_MAIN), 0, DllDlgProc);
I looked at the KB article. It sounds reasonable. There is some point where you was not enough accurate while following the instructions from KB. Post your code. This may help.
If you have control over the message pump of the executable and can add IsDialogMessage there, then you do not need any hook. Code from the dll is part of the code of the process. Window handles are in the common space either.
Other approach is starting your own UI thread. If you create your dialog on this thread, then you will have your own message pump. The hook will not be needed in this case either.
Well, this is more of a question to author of the post..
I have the tab key issue and am trying to understand the microsoft article better.
So my dialog is shipped out as Dll and the application which I don't have access to is launching dialog from my dll.
HWND hwndDllDlg = CreateDialog(0, MAKEINTRESOURCE(DLG_MAIN), 0, DllDlgProc);
I don't understand what dialog the code refers to when they said hwndDllDlg in the article. Should I point my dialog creation to this variable ?
I created win32 wrapper before but I lost the files... So I'm gonna creating them again. The problem is with my router(static window processor).
Here is my code
CFramework *wnd = 0;
// retrieve associated Window instance
wnd = reinterpret_cast<CFramework *>(::GetWindowLongPtr(hWnd, GWL_USERDATA));
// call the windows message handler
wnd->WndProc(hWnd, msg, wParam, lParam);
return true;
When I call GetWindowLongPtr it won't retrieves the user data.
UPDATE:
I also tired this code that uses SetWindowLongPtr
if ( msg == WM_CREATE )
{
SetWindowLongPtr( hWnd, GWLP_USERDATA, (LONG)((CREATESTRUCT *)lParam)->lpCreateParams );
}
Window *targetApp = (Window*)GetWindowLongPtr( hWnd, GWLP_USERDATA );
if ( targetApp )
{
return targetApp->WndProc( hWnd, msg, wParam, lParam );
}
return DefWindowProc( hWnd, msg, wParam, lParam );
I used my second code.^^^^
I put break point at SetWindow...
It seems it never Get called!
Your window may receive some messages before WM_CREATE. I did something like this a while ago, and there were sizing and positioning messages, along with WM_NCCREATE, that arrived before the WM_CREATE. So you shouldn't expect to see the value there on those messages.
Are you compiling for 32-bit or 64-bit? If 64-bit, then the cast to LONG may be whacking your pointer.
And, as Rup said in the comments, you have to be really certain that nobody else is using WM_USERDATA.
I want to print out a message using MessageBox (or similar). I would also like control over where exactly on the screen the box appears but can find nothing in the description of MessageBox that allows you control over the location. Did I miss something? If MessageBox can not be used, then is there an alternative?
For reasons too complex to go into here, I would prefer an answer which didn't involve making my own window and passing the address of a callback function.
Step 1: Create a CBT hook to trap the creation of the message box:
// global hook procedure
HHOOK hhookCBTProc = 0;
LRESULT CALLBACK pfnCBTMsgBoxHook(int nCode, WPARAM wParam, LPARAM lParam)
{
if (nCode == HCBT_CREATEWND)
{
CREATESTRUCT *pcs = ((CBT_CREATEWND *)lParam)->lpcs;
if (pcs->style & WS_DLGFRAME || pcs->style & WS_POPUP)
{
HWND hwnd = (HWND)wParam;
// At this point you have the hwnd of the newly created
// message box that so you can position it at will
SetWindowPos(hwnd, ...);
}
}
return CallNextHookEx(hhookCBTProc, nCode, wParam, lParam);
}
Step 2: Install/remove the hook before and after showing the message box:
// set hook to center the message box that follows
hhookCBTProc = SetWindowsHookEx(WH_CBT,
pfnCBTMsgBoxHook,
0, GetCurrentThreadId());
int sResult = MessageBox(hwndParent, pszMsg, pszTitle, usStyle);
// remove the hook
UnhookWindowsHookEx(hhookCBTProc);
If I needed additional behavior for a Messagebox I always created my own window and made it look like a standard MessageBox. You do it right once and you can always reuse it in other projects.
MessageBox is a basically a set of defaults. Don't like them? Bring your own. If you don't want a real window with all its complexities, but MessageBox is too restrictring, create a dialog.
You could do this with a CBT hook procedure. There is an MSDN article on how to do this in VB but converting it to C++ wouldn't be hard.
http://support.microsoft.com/kb/180936