🚀 go-pugleaf

"salamander1965" <salamander1@verizon.net> wrote in message 
news:485ac9db$1@newsgroups.borland.com...

> I played around with the message boxes a little more, having them
> also report the hMod parameter that came in to the DllEntryPoint()
> function and which was subsequently used in the call to
> SetWindowsHookEx().

The DLL is loaded separately into every running process.  The hMod passed 
into DllEntryPoint() should be different for each DLL instance, as each DLL 
instance is mapped into a different address space.

> The value of hMod is the same for each of the app instances that
> are started

I don't see how that can be.

> By putting a MessageBox() call in the hook procedure itself, though

You might consider using OutputDebugString() instead.  Then you can use an 
external log viewer, such as SysInternals' DebugView, to see the messages in 
real-time without having to pause to read and dismiss individual popup 
dialogs.  You could output the calling process name, hook reference count, 
etc in a simple text format for easy reading and logging.

> I found that it's not the termination of the first app instance that 
> deactivates
> the hook, but instead the detaching of Explorer.exe from the DLL that
> immediately follows the detaching of the first app instance, even though
> it was in the context of the first app process that the hook was set.

But you have your DLL code set up to allow any DLL instance to release the 
unhook, not the first instance exclusively.  That would suggest your hook 
data's reference count is somehow falling to 0, causing one of the DLL 
instances to call UnhookWindowsHookEx() even though other apps are still 
running.

> If you have any idea what's going on as things stand now, I'd like
> to hear it.

I have no clue.

> In the meantime, though, I'm going to try the approach you suggested
> (for which, thanks).  Just working it out on paper at this point, I think
> I see how to go about it -- something like this:
<snip>

Yes.

> the instances of the app somehow need to 'know' if they are the last to 
> terminate so they can terminate hook.exe (which will unload the
> DLL) before closing.

You can use window messages or other IPC to communicate with hook.exe.  Each 
instance could register/unregister itself with hook.exe so it knows how many 
apps are running.  Or just broadcast a custom window message and see if any 
apps respond to it.

> Since there's really no reason for hook.exe to have a message loop

That depends on which communication model you choose to use, if any.


Gambit