error LNK2019: unresolved external symbol __imp__setMyHook referenced in function "protected: void __thiscall CHookDlg::OnEnable(void)" (?OnEnable@CHookDlg@@IAEXXZ) C:\Users\kmunir\Downloads\hooks\HOTT\hook\hookDlg.obj
error LNK2019: unresolved external symbol __imp__clearMyHook referenced in function "protected: void __thiscall CHookDlg::OnEnable(void)" (?OnEnable@CHookDlg@@IAEXXZ)
This method is included in the MouseHook library that is separate.
You need to first convert & build the included MouseHook project (.dsp file).
Then you need to update the C\C++ and Linker references in the Hook project so it is able to load MouseHook.lib
Though old thread maybe I get an answer here for my issue.
My application uses a custom dll which creates a hook.
Let's call this MyTools.dll
The dll posts message to my application which in turn displays the event in a GUI.
But this MyTools.dll offers also other handy functions for my application.
Some of these functions need dependency dll's. The dll is linked to those dll's.
Let's call this dependency X.dll. This dependency X.dll is deployed in the same folder as my application.
The hooks seem to work up until specific other applications (for example wlmail.exe, the MS live mail application) throws an errormsgbox indicating that X.dll can not be found.
Seems that when MyTools.dll is injected to wlmail.exe and calls the hook procedure is trying to load X.dll. As this dll is only known by my application (there is no PATH to it defined in the PATH system var) the other process can not load it.
But strangely, the hook procedure itself does not call X.dll. It only posts the message. No use of any X.dll feature.
Seems that even when the hook proc has nothing to do with X.dll, the MyHook.dll still wants to load it and it can not.
How to prevent this? Is there a way that in the example wlmail.exe the hook is called without trying to load/use the dependency X.dll?
To be able to delay, a default lib must be used. This is set by the first line.
The DelayImp.lib is part of VS install.
The second line sets which dll should be delayed for loading. This means that the dll you specify there will only be loaded when the first exported item is called from your hook dll.
So when no functionality is called, the dependancy dll will not be loaded.
Replace "DEPENDANCY.dll" with the dll name you would like to delay.
This actually solves my issue. When a process loads my hook.dll, there are no issues anymore that hook.dll loads the dependencies. Only my hook function will be used and no error msg pops up.
I downloaded the supported code and let vs2013 community edition to migrate it. After fixing MSB8031 I could build the solution and run it under win7 from the studio and launching the exe from total commander as well.
After that I tried to capture WM_LBUTTONDOWN without success except the mouse was over the cat's window that is over the main app.
Over TC and task manager even the mouse position was not captured, so I tried to run the app as administrator but without any success.
Since the mouse position can be read using GetCursosPos using a hook for only this purprose is pointless.
Perhaps I did something wrong. Could you be so kind to add WM_LBUTTONDOWN handling to msghook and see whether it works? I would be more than happy, since it is really flustrating that I could not manage to write a mouse catcher while it seems it is straightforeward.
Perhaps my problem is related to the 32/64bit dll injection problem discussed in the "SetWindowsHookEx" msdn documentation. Unfortunately I am too unexperienced on this field
My dll need to hook with all the running process and when i click left mouse button on any application window like firefox or iexplorer it should take a snap. the dll is hooking properly i guess but it is not processing the mouse events please help me out......
It's a serious problem. Indeed, you cannot use PostMessage for WM_COPYDATA. What you probably have to do is do it in a separate thread using SendMessage.
It will not "speed up" the sending app, but it won't block the sending thread if you use a secondary thread to send the data. So if the sending thread is the main UI thread, you will have the illusion of faster performance (no blocking of the main UI thread) but the net time will be probably slightly longer because of thread swap overhead.
Yes. When your hook runs in some other application, the DLL itself is loaded into that application! Since the data is no longer shared, this means that the only DLL that has the correct information about where to send the message is the instance running in your program. While the other instances of the DLL can (and do) run in other applications, they have no idea how to send information to your app, because they are not sharing the variables, hence every copy gets its own private, initialized-to-NULL-or-zero, variable, which consequently contains no useful information. Also, they cannot forward the hook call, so other hooks that might exist would also stop working.
You are seeing what is the defined behavior of non-shared memory. The reason we need to have shared data is so that the DLL can work in the context of other processes.
I have read your article about global hooks, it is very well written, thank you very much indeed. I am trying to listen to Raw Input messages but it is being very difficult for me to support those kinds of messages (seconday HIDS) with your Global Hooks library.
My problem: All raw input examples do track local secondary keyboard an mouse events, but no example does track them globally. No global hooks dll seems to support raw input.
I am sending code to you that allows to listen to local raw input messages, could you help me adding support for this kind of messages to your dll? it would really be a valuable add on to it. It seems to me that it should be easy for you to code it. if I am not wrong, what it should do is remap raw input messages to C#, as it does with mouse events, but it is really getting hard for me to get it :/.
I will really appreciate your help. The local rawmouse code my be downloaded from http://www.jstookey.com/arcade/rawmouse/ .
It has come to my attention that when you call SetWindowsHookEx, you store the returned value in a global var called hook. This is done in order to call UnhookWindowsHookEx with the same value returned by SetWindowsHookEx.
Also, in the hook procedure, you use this variable in order to call CallNextHookEx and here is my cuestion.
You have two (or more) different processes. The one that installed the hook, and the one (or more) hooked. The one that installed the hook has a correct value in the global variable hook, but the hooked ones has this var in an undefined state: The initializacion was made in a different process and this means that it was done in a different address space.
As a result, in the call to CallNextHookEx you are passing an undefined value as first parameter, or NULL in the case you initialized that var to NULL (HHOOK hook=NULL)