Reply to thread

I've released a new beta version of KeyboardInputPlugin 2.4.0.0. The MediaPortal Extension Installer version can be downloaded at https://mp-plugins.svn.sourceforge.net/svnroot/mp-plugins/trunk/plugins/KeyboardInputPlugin/MPE/KeyboardInputPlugin.mpe1. If you've previously installed the KeyboardInputPlugin MPE package, you may need to uninstall it and clear the MPE installation cache.

You can also download the full package containing sources and release as a GNU tarball from http://mp-plugins.svn.sourceforge.net/viewvc/mp-plugins/trunk/plugins/KeyboardInputPlugin/?view=tar for manual installation. Please note that the HISTORY.HTML and README.HTML files may not be completely up to date yet.

Changes in this version are as follows:

• Extensive code clean-up.
• Simplified key processing.
• Win-keys can be used as modifiers again.
• Looks like the plug-in can intercept almost all keystrokes, at least in the test program; from simple keystrokes like 'A' to key combinations like Ctrl-Alt-Shift-Win-A. Within MediaPortal it looks like you can even override system keys like Win+E.
• Keys handled by the plug-in will not be passed on to MediaPortal, so no need to remove the MediaPortal keymap.xml file.
• Keys not handled by the plug-in will be passed on to MediaPortal, other plug-ins and/or Windows. So Keyboard.xml and keymap.xml supplement each other, and keys like Win+E will have their usual behavior even when the plug-in is active (unless the key combination has been redefined in KeyboardInputPlugin).

By looking at the code (don't have my MediaPortal installation at hand right now) I think we still need to look at the following:

• I think the plug-in will intercept keystrokes even when MediaPortal is running in the background; if possible we should probably check if MP has focus (for example in KeyboardInputPluginMain.KeyboardHandler_IsActiveIndicator method). This is already handled by KeyboardInputPluginMain.form_Activated/form_Deactivate.
• It looks like other keyboard hooks will not be invoked if a key combination is handled by the plug-in; I'm not sure whether we should want this or not. Changing this would require copying MP's Hook.cs into our project and modifying the InternalHookDelegate method to always invoke CallNextHookEx (and at the end return 1 if e.Handled==true, otherwise return result of CallNextHookEx).
• We simply ignore (pass through) modifier key presses, and only check for currently pressed modifier keys whenever any other key is pressed. In theory this could cause an application to see for example just an Alt keypress if the user presses Alt+X (if Alt+X is handled by the plug-in), which could cause strange behavior. I haven't seen any strange behavior during testing, but we should double check this. Double checked, seems to work correctly
• We still need to fix the keyboard hook de-activation problem on Windows 7. Some possible solutions:
  
  • Fix using registry hack: Not needed; fixed at code level
    
    • Automatic installation of registry hack during MPE install. This poses a problem; the registry entry is under HKCU, but the installer is run as Administrator I think. So we would need to find out the user that is used to run MediaPortal and update the registry key under HKU\<user>.
    • Manual installation of registry hack by installing a .reg-file that users can manually run (as the MediaPortal user).
    • Detection and auto-install of the registry hack from the plug-in. However, the registry hack requires a restart.
  • Fix at code level:
    
    • Maybe running the keyboard hook in a separate high-priority thread can help solve the problem; we're currently probably running as part of the MP UI thread, and due to that may have to wait until MP has processed a message before the keyboard hook can be invoked by Windows. Probably fix below is enough; if not we could still implement this in addition.
    • Automatically detect when the keyboard hook becomes inactive and re-enable it. For example, set lastHookKeyDownTime to the current time on hook invocation, and implement IPluginReceiver.WndProc, setting lastWndProcKeyDownTime to the current time on WM_KEYDOWN/WM_SYSKEYDOWN messages. Compare these times, and if necessary (lastHookKeyDownTime<lastWndProcKeyDownTime, before updating lastWndProcKeyDownTime to current time) restart the keyboard hook. WndProc may not see all key presses that are usually handled by the plug-in (and has some other problems that prevent us from using it instead of a keyboard hook) so the plug-in may skip a few key presses, but at least you won't have to restart MediaPortal. Implemented in new version (to be released in a few days)

Please test this version on your system and give us your feedback on how it works. Have fun!