Well my SetWindowsHookEx call appears to succeed. However it appears
to succeed if I pass it the address of anything (I gave it a pointer
to an Int), not just the Callback function. I don't get any effect
from the hook, but it could be that I don't have this threaded
properly for it to work. However I think I probably cannot install it
globally as is. MSDN seems very adamant about the function coming
from a DLL, see what I pasted below. So instead, what if I created a
DLL that Bridj could stash away specifically to interact with Hooks,
and then that Bridj DLL talked to the Bridj Callback function as an
intermediary. In the Java code my hook handler could then inherit
from Hook<SomeMethod> instead of Callback<SomeMethod>
From MSDN :
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644960(v=vs.85).aspx#installing_releasing
"A global hook monitors messages for all threads in the same desktop
as the calling thread. A thread-specific hook monitors messages for
only an individual thread. A global hook procedure can be called in
the context of any application in the same desktop as the calling
thread, so the procedure must be in a separate DLL module. A thread-
specific hook procedure is called only in the context of the
associated thread. If an application installs a hook procedure for one
of its own threads, the hook procedure can be in either the same
module as the rest of the application's code or in a DLL. If the
application installs a hook procedure for a thread of a different
application, the procedure must be in a DLL. "
"You must place a global hook procedure in a DLL separate from the
application installing the hook procedure. The installing application
must have the handle to the DLL module before it can install the hook
procedure. To retrieve a handle to the DLL module, call the
LoadLibrary function with the name of the DLL. After you have obtained
the handle, you can call the GetProcAddress function to retrieve a
pointer to the hook procedure. Finally, use SetWindowsHookEx to
install the hook procedure address in the appropriate hook chain.
SetWindowsHookEx passes the module handle, a pointer to the hook-
procedure entry point, and 0 for the thread identifier, indicating
that the hook procedure should be associated with all threads in the
same desktop as the calling thread. This sequence is shown in the
following example."
Chris
> 2012/1/16 cessationoftime <
cessationoft...@gmail.com>
>
> > Yes, GetModuleHandle(NULL) successfully returns a handle. I have not
> > tried using that handle to call SetWindowsHookEx as yet though. The
> > example I had made me think that GetModuleHandleEx was required, but
> > of course they were loading their function to SetWindowsHookEx from a C
> > ++ DLL. I will try that tonight and see if it will work for me.
>
> I can't think of a reason why it wouldn't work, but please keep us posted !
>
> > If it fails though I was considering trying to build my function in
> > the D language and link the JVM to the win32 API through D instead.
> > Are you aware of anyone trying to use Bridj with D ?
>
> That would probably be a first, and would probably yield *interesting* bug
> reports :-)
>
> Cheers
> --
> Olivierhttp://ochafik.comhttp://
twitter.com/ochafik