Strange thing with XP Theme Support ON

[Mark Strickland]

Paul,

You gave me some code for handling function keys using the KeyBoardHookFunction.  I turned on XP Theme support (did a full code generation and compile) and it appears that this no longer works and will not intercept keystrokes.  I have not yet debugged exactly where the failure occurs but I simply turned off XP Theme support and did a full code generation compile and it works again.

Any thoughts?

If there is a hole it seems I can find 'em and step in 'em !!!!

Thanks.

[TechSupport]

That is odd. I can't imagine why a XP Themes would interfere with a keyboard hook. Windows is certainly a weird beast.

I wonder if the RegistryHotKey approach may work better?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardinput/keyboardinputreference/keyboardinputfunctions/registerhotkey.asp

[Mark Strickland]

I thought my XP Theme problem had "disappeared" but it was OPERATOR ERROR (me).

The keyboard hook works fine until you focus input on another running program and return to the FF generated app.  When you return the KEYBOARD HOOK never fires again.

Not related to minimize/restore but simply having the focus change to another running program.  XP must re-fix up the hook.

I even tried the exe on another machine and disabled the firewall (Norton) but it works the same.  The hook gets un-hooked.

Paul, you mentioned the RegisterHotKey call but that would mean I would have to register every possible function key with shift and control options.  I can do that but it is a little messy.  PLUS the MSDN article says it is a system wide key so I assume that EVERY running app would post a message --- not a good thing.

Soooooooooooo

Any more thoughts other than turn off XP Theme support?

[Mark Strickland]

This is the call to set up the hook

SetWindowsHookEx(

   int idHook,   // type of hook to install
   HOOKPROC lpfn,   // address of hook procedure
   HINSTANCE hMod,   // handle of application instance
   DWORD dwThreadId    // identity of thread to install hook for
  );

I am specifying dwThreadId as zero.

dwThreadId
Specifies the identifier of the thread with which the hook procedure is to be associated. If this parameter is zero, the hook procedure is associated with all existing threads.

So it appears that maybe since it is associated with all threads and XP Theme support is on other threads (in other processes??) un-hook it.

MSDN has some comments about global versus thread specific but it will take a bit of study to understand it.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/hooks/hookreference/hookfunctions/setwindowshookex.asp

[Mark Strickland]

I used

   mythread = GETCURRENTTHREADID()

and then used the thread ID that was returned to set the hook ---

   ghHook = SETWINDOWSHOOKEX( %WH_KEYBOARD, _
                              CODEPTR(KeyBoardHookFunction), _
                              App.hInstance, _
                              mythread)

SUCCESS!

When you use zero as the thread ID it is GLOBAL to the desktop.  It appears that with XP Theme support turned on other apps can "monkey" with this and it gets disabled.  Strangely with XP Support off it seems not to happen (although I saw a few random incidents that I could not reproduce with themes off).  Related

The only potential issue is --- DOES FF use multiple threads?  The one I capture is in the CREATE of the startup form.

Ahhhhhhhh ---- It only took me #$%@@#%^ hours to figure this out.

[TechSupport]

Very good work Mark. You see, Windows is not that difficult afterall [insert sarcastic smile here]