enanno: Funny I played with it for 1 hour now. And still everything works fine.
I'm sorry, I uninstalled MediaPortal from "the other" PC. I'll give it a try later.
Now, here we go with my main PC.
I've just tried your the second dll you've attached, and put MediaPortal y Debug mode. Here you have my View attachment 92740 file, but I have to tell you that even if it's less agressive than first dll, the second one still does "nothing" when I push Enter. The actions I do are similar than before, I mean, I go to Videos, Películas, choose one movie, and push enter button until at 5th or 7th time it runs. Then I push Fullscreen button and MediaPortal gets windowed again.
I miss Windows XP hahahah
I'm sorry, I uninstalled MediaPortal from "the other" PC. I'll give it a try later.
Now, here we go with my main PC.
I've just tried your the second dll you've attached, and put MediaPortal y Debug mode. Here you have my View attachment 92740 file, but I have to tell you that even if it's less agressive than first dll, the second one still does "nothing" when I push Enter. The actions I do are similar than before, I mean, I go to Videos, Películas, choose one movie, and push enter button until at 5th or 7th time it runs. Then I push Fullscreen button and MediaPortal gets windowed again.
I miss Windows XP hahahah
One main difference between the two DLL versions is that the original version passed keys through to MediaPortal if a mapping was defined for that key, but none of the mapping conditions were met. The new version simply doesn't pass through any keys that have been defined in the mapping, regardless of whether any mapping conditions are met or not.
According to your log, the Enter key is defined in the KeyboardInputPlugin mapping, so with the second DLL this key is never passed through to MediaPortal. I guess this key was passed on to MP in the original plug-in because none of the conditions in this mapping were met.
I could re-introduce the original behavior, but that means (a little bit) more processing code inside the hook, so a (slightly) higher chance that the hook times out. As an alternative, you can add a 'No Condition' -> 'Select Item' action to the Enter key mapping in KeyboardInputPlugin.
I would like to know the opinion of other users on this matter; should the plug-in pass through any keys for which none of the conditions are met, or should the plug-in simply intercept all keys defined in the mapping, irregardless of conditions?
However... the "bug" is still there... In this View attachment 92744 file I now attach. I push 5 times the Fullscreen button on my remote, being the fifth time when the thing fails. Hope it helps you.
I didn't expect the bug to disappear completely. The question is however, do you think the bug occurs less frequent now?
With the new DLL the keyboard hook has been optimized to use as little time as possible. The main change is that the mapped action is performed asynchronously, outside of the hook.
The hook is still running in the context of the main MediaPortal UI thread however. So, if MP is busy doing something on the main UI thread when you press a key, the main thread first has to finish what it's doing before the hook can be invoked. If the hook cannot be invoked in time, it will still be disabled.
As discussed before, I can try to run the hook on another thread with its own message loop. However, I'm not sure whether I will be able to block key events being sent to the main MP UI thread in that case. If I cannot block the key events, each key press will be handled by both the plug-in and MP.
Of course, man. It works better now, and I thank you.I didn't expect the bug to disappear completely. The question is however, do you think the bug occurs less frequent now?
Of course, man. It works better now, and I thank you.I didn't expect the bug to disappear completely. The question is however, do you think the bug occurs less frequent now?
I have created yet another version of the DLL. Together with the earlier changes, the keyboard hook now runs in its own thread. As such, if MediaPortal is busy doing something on the main UI thread, the hook will still be called in time. Of course, if your system is under a really high load and/or paging a lot, a time-out may still occur.
<Edit: text removed>
Can you please test this DLL and let me know the result? Logs are now less useful for me, as I can't see whether a time-out has occurred (due to disabled recovery mechanism). Just do the same tests as before and check whether you can still get Alt+Enter to trigger full-screen/windowed mode instead of aspect ratio.
Edit: Updated DLL; please re-download if you downloaded the attached DLL before 2011-11-19 8:40. The new DLL executes the MapAction method on the main MP UI thread by using GUIGraphicsContext.form.Invoke().
Edit: Updated DLL; please re-download if you downloaded the attached DLL before 2011-11-21 16:00. The new DLL should have all possible threading issues fixed, code has been cleaned up, etc. The handler time-out recovery mechanism is still disabled as I think it is not needed anymore now that the keyboard hook is running in its own thread.
Request to everyone using this plugin; if you have the time please test this DLL and let me know whether it works correctly for you. If results are positive I will incorporate the changes in a new MPE-installable version of the plug-in.
Thank you very much for all, and I hope you release it as an official version soon.