home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
MediaPortal 1 Plugins
Generic Keyboard/Remote Input Plugin
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="rsenden" data-source="post: 811667" data-attributes="member: 24295"><p>The problem is that the hook gets disabled even when Windows is not low on resources. I've done some more testing; I actually already implemented the faster key mapping lookup and temporarily disabled actually executing the action. This results in the keyboard hook being disabled less frequently, although still quite often. It looks as if the hook gets disabled whenever a key is pressed while MediaPortal is doing 'something' (for example while loading a new screen).</p><p></p><p>According to <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms644985%28v=vs.85%29.aspx" target="_blank">LowLevelKeyboardProc callback function</a>, the hook is called in the context of the thread that created it by sending a message to that thread. As I don't do any thread management myself in the plug-in, I guess the hook is installed in the main MediaPortal UI thread. Could it be that MediaPortal blocks the message queue while 'doing' something, resulting in the hook not being called in time?</p><p></p><p>Maybe we could install the hook in a separate thread, with its own message loop? However, I'm not sure on how to implement that, and whether that would actually work. For example, maybe each thread will then handle key presses independent from the other, resulting in a situation that MediaPortal still sees the key press on the main thread even when it was handled by the hook in the second thread?</p><p></p><p>I'm no Windows expert (usually I only do Java development), so I'm just guessing here...</p></blockquote><p></p>
[QUOTE="rsenden, post: 811667, member: 24295"] The problem is that the hook gets disabled even when Windows is not low on resources. I've done some more testing; I actually already implemented the faster key mapping lookup and temporarily disabled actually executing the action. This results in the keyboard hook being disabled less frequently, although still quite often. It looks as if the hook gets disabled whenever a key is pressed while MediaPortal is doing 'something' (for example while loading a new screen). According to [url=http://msdn.microsoft.com/en-us/library/windows/desktop/ms644985%28v=vs.85%29.aspx]LowLevelKeyboardProc callback function[/url], the hook is called in the context of the thread that created it by sending a message to that thread. As I don't do any thread management myself in the plug-in, I guess the hook is installed in the main MediaPortal UI thread. Could it be that MediaPortal blocks the message queue while 'doing' something, resulting in the hook not being called in time? Maybe we could install the hook in a separate thread, with its own message loop? However, I'm not sure on how to implement that, and whether that would actually work. For example, maybe each thread will then handle key presses independent from the other, resulting in a situation that MediaPortal still sees the key press on the main thread even when it was handled by the hook in the second thread? I'm no Windows expert (usually I only do Java development), so I'm just guessing here... [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Plugins
Generic Keyboard/Remote Input Plugin
Contact us
RSS
Top
Bottom