Click here to Skip to main content
15,867,986 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
I have a thread hook dll that I've injected into another process.
Everything is cool except the most annoying fact that if one declares:

DWORD i;
i = wParam ; // from a WM_USER trap for instance

Anywhere in the dll code (shared area, global declaration or inside the hookproc) every time
the hook proc is called i is re-declared and the value of i is reset. I need it to hang around for a while till I deem it usless.

This is unavoidable isn't it?

:Ron

additional information copied from comment below
Perhaps this will clarify better. It describes the exact problem and the thread dies.

http://forums.codeguru.com/showthread.php?125092-Accessing-global-variables-inside-a-hook-procedure-in-a-simple-win32-dll[^]
Posted
Updated 2-Sep-14 9:48am
v4
Comments
Sergey Alexandrovich Kryukov 1-Sep-14 22:20pm    
Not clear. Frankly, sound like gibberish to me. Saying that you declare DWORD variable (member of stack variable?) says next to nothing. You need to explain a lot more detail about the issue (if it is an issue at all).
—SA
Ron Anders 1-Sep-14 23:16pm    
Perhaps this will clarify better. It describes the exact problem and the thread dies.

http://forums.codeguru.com/showthread.php?125092-Accessing-global-variables-inside-a-hook-procedure-in-a-simple-win32-dll

I think what you are looking for is a simple "static" variable. Just declare your variable as
C++
static DWORD sSomethingMoreDurable = 0;

and it will keep its value until the dll is unloaded or the process ends.
 
Share this answer
 
Comments
Ron Anders 2-Sep-14 12:30pm    
I thought I tried that. I will revisit that.
Ron Anders 2-Sep-14 14:37pm    
Gosh, I know I tried that! - But it's working now.

I can't thank you enough nv3.
nv3 2-Sep-14 18:10pm    
You are welcome.
You can always write the value you want to keep to a file, and reread it when needed.
 
Share this answer
 
Comments
Ron Anders 2-Sep-14 8:57am    
That's what I am doing now as a work around.
A poor man's IPC bounced off of c:\mosedoubleclick.dat where I store the state of a double click so that when a hooked WM_CREATE comes next, I can act accordingly. This may be too slow
as it woks well in the debugger but misses when running full speed suggesting that the drive IPC is too slow.

The process that knows about the mouse state is 64 bit and the hook is running in a 32 bit process. That coupled the fact that I cannot persist a value or object for subsequent calls to winproc complicates any other normal IPC methods such as MailSlot for instance, where the reader (which would have to be the hookpropc) must be the mailslot creator and so on.

:Ron

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900