Glad to hear it! I’ll hold off a few days on updating the plugin again just in case you find anything else that needs to be tweaked 
1 Like
Cool. I have only found one issue so far with media/shortcut buttons not working on a particular website - but they work on all others I have tested, so it’s likely the website/player that is the issue.
If I get the time at the weekend I’ll piece together what is going on, but it’s unlikely that it’s a THR/plugin issue as I say.
Thanks,
Shuggs
Hey! @hotelfoxtrotnovember
Life and holidays have got in the way of continuing my remote setup recently but I’ve managed to get back into it and do some pretty thorough testing on the MCEC plugin, keyboard and mouse. Here’s what I have found…
1. WOL has worked flawlessly, even when I returned after a week away and the HTPC had been physically unplugged. Works a treat!
2. Touchpad selection. As we previously discussed, this refers to holding the mouse down and drag-selecting text/areas/items. Refer to previous post passage…
This is working, with one caveat - it feels like it is overly sensitive and I (and more so my partner) find a lot of the time we’re simply trying to accurately focus the cursor on a certain area/button it often triggers the drag-select mode instead. I feel like this may be much less intrusive with a longer delay on the drag mode being enabled - maybe 0.75 > 1 second. At least this way, we’d know to trigger the drag-mode that we very deliberately need to hold down for x time.
To avoid any wasted time/effort up front on your behalf, is there any way this can be altered or even exposed on a variable much like the other mouse-related variables in the index.html??
3. As mentioned in my last post, various browsers/players do not work with keyboard shortcuts. It seems that sites like YouTube work correctly because they use native keyboard commands. However, some of the subscription/TV sites obviously use third party media players and UI so the key shortcuts do not work or function incorrectly.
Here is a good example for you (although if you’re in the US you will be unable to test this out). Using the BBC iplayer, the following shortcut keys will trigger these commands:
- Back 20s (LetterJ / DirectionLeft)
- Skip 20s (LetterL / DirectionRight)
- Play/Pause (LetterK)
- Fullscreen (LetterF)
- Subtitles (LetterS)
If I use a physical keyboard all of the above commands work perfectly. Using the THR remote, if any of these keys are pressed, they only force the player overlay to appear - none of the actions (skip forward, pause, fullscreen, etc) are actually performed. I’ve tested this in Chrome, Opera & Vivaldi browsers with the same results. There are other sites/players I have seen similar behaviour.
Interestingly, my Logitech Harmony remote does work with the iplayer and other sites - and looking at the key assignment in the Harmony app, it uses the exact same commands (DirectionLeft, ‘F’ key, etc).
As I am a dunce when it comes to the code side, keystroke sending/commands, etc I wondered if you had any inkling on how to get this to work?
Is this related to your very first post where you mention the way the keys are sent/registered in MCEC?
As always, thanks for your help!
Apologies for the delay, I was out of town and just saw your post. Glad to hear WOL is working!
Regarding the dragging mode, the MouseHelper uses hammer's default press detection, which according to the docs here is 251 ms, if I’m reading it correctly. You should be able to modify this line in the index.html:
pressRecognizer = new Hammer.Press();
to be something like:
pressRecognizer = new Hammer.Press({
time: 750,
});
I don’t have time to test this right now so I’m going off the syntax for configuring some of the other recognizers already in that file, but I’m fairly sure that should work. If that works for you, please let me know and I can add it to the main configuration section.
Regarding the last point, I only use Plex on my HTPC and, on occasion, use the keyboard for general Windows configuration/maintenance, so I can’t say I’ve encountered those specific issues. But, as you note, it may be related to the way MCEC sends keystrokes/its virtual keyboard–I don’t think this is a THR/plugin issue. I wonder if the Harmony remote uses a different keyboard-type interface/mechanism to send those commands? The creator of MCEC was fairly helpful when I reported a number of bugs/inconsistencies (not related to this), so it might be worth trying to open a ticket with him to see if he has ideas on MCEC's interaction with such third-party media players. Sorry I can’t be more help with that one, but there are aspects of MCEC that still baffle me somewhat
1 Like
Thanks for the quick fix - that code replacement in the index.html is spot on. After some tweaking we’re now finding it much easier using a longer delay of ~700 which pretty much eliminates the accidental drag-select triggering. Much happier to have the drag-select as a more deliberate action, so thanks for making it happen!
I managed to find a workaround to get the iplayer media keys working - by creating scripts in Autohotkey. I’ve been using Autohotkey scripts for various shortcuts and maintenance tasks but realised I could just setup THR to use simple Autohotkey scripts that trigger the keys locally on the HTPC itself. The direction keys worked straight away, but I found that the letter keys (s,f,k, etc) only work if they are lower case so there must be some case-sensitive shenanigans under the iplayer bonnet.
FYI, even though the autohotkey scripts are basic, if anyone is interested here is an example of the ‘s’ key which toggles the subtitles in iplayer:
#NoEnv
SetWorkingDir %A_ScriptDir%; Send the ‘s’ key (case sensitive for iplayer)
Send {s}Exit
I haven’t had a chance to test the other media players yet - if I have any issues that Autohotkey can’t fix, I’ll contact the MCEC guy as you suggested. Thanks for the tip!
This plugin & MCEC has really transformed our home AV setup in general. Even my partner now prefers using THR on a tablet, to the point where she can’t go back to the handheld remotes because they lack the speed and functionality. 
1 Like
I’ve updated the index.html file in the main MouseHelper post so that this is now easier for others to change the minimum press time configuration. Thanks again for your help with this, @Shuggy!
1 Like
No problem! @hotelfoxtrotnovember It’s all you man - your support and work on this is incredible, so thanks again. 
I’ve been tinkering with my layout (changed to UK spec, moved some keys around, removed redundant stuff, etc) and started building a UI that I can patch into my activity pages. The idea is that the keyboard is clean and compact - as I use it in portrait mode. I’ve removed the arrow keys and will add a d-pad, zoom controls and windows shortcuts underneath.
The mousepad is anchored at the top, below is a scrolling panel which contains the activity-specific controls, media player panels, keyboard, etc - so the mousepad is always present, but you can scroll through the controls below.
Here’s a quick (compressed) gif of the current setup using image buttons (this took a lot of time rebuilding the buttons to swap images and avoid the android ripple anim on my tablet). 
1 Like
Hey @hotelfoxtrotnovember
Just a quick question regarding the touchpad/scrollbar: Is there any way of triggering feedback when the touchpad or scrollbar are pressed?
As the touchpad is done on the MCEC side I’m not sure if there’s any way THR can know when it has been pressed. I tried adding an event trigger to the WebBrowser element, but THR just threw an error when the page was loaded.
Cheers!
Shuggs
I’m not sure. What kind of feedback did you have in mind?
Image, text, anything really. Currently, I trigger ‘IsPressed’ images for buttons - so I already do this for the left and right mouse click.
Something similar for interacting with the touchpad (and ideally the scrollbar separately) would be nice.
THR WebBrowser elements do not seem to have any trigger functionality other than Loaded/Unloaded though. So it feels like there would need to be a change on the THR side with WebBrowser interactions (even if there was something to track/monitor on the MCEC/mousehelper end).
Just thought I’d ask in case I’d missed something blindingly obvious.
This is a good news, bad news, situation, I think.
The good news is I think what you want to do can be done. In the index.html file, I think in the various hammer.on() handlers, that’s where the feedback effects should be added. If I’m remembering how this all works correctly, those fire every time an event trips. In addition, the scroll region has a separate scrollHammer.on() handler, so those should be able to be handled separately.
The bad news is I have no idea how to actually provide the feedback. My knowledge of html/javascript in this context is paper thin, unfortunately. Maybe someone with more skills than I in that department can help out?
1 Like
No problem! My knowledge of html/js is close to nothing so I fully understand. It’s a nicety at the end of the day - I asked more in hope of there being a simple solution I was overlooking. As you say, maybe someone else will know how to integrate the feedback - though even with the mousehelper work I suspect it will stall requiring THR-side integration.
Thanks anyway - your help is always appreciated.
Thanks for taking the time to share and detail this solution @hotelfoxtrotnovember, much appreciated and you have saved HTPC users like myself a lot of time/frustration.
I have this deployed in my setup and have one issue I’m not sure how to address - the embedded web browser used for mouse control works fine for me in a tabbed page or popped page, but when I open that same keyboardmouse.xaml with embedded web browser in a pagebrowser, (which is utilized in my setup to quickly toggle control types within a room) only the first few to dozen or so mouse movement commands are received by MCE and the rest never register (mouse stops moving even though still dragging finger). Again when I open in a tabbed page or popped page, all movements are continually tracked in MCE and use is seamless.
Does anyone that has deployed this have any idea what might cause this behavior? Thanks for the help!
That’s an interesting issue, @mastpryix. If I had to guess, I would suspect it is either a THR bug or a platform-specific bug of some variety. I don’t have my WebBrowser control within a PageBrowser so I can’t say that I have observed that particular behavior, but it wouldn’t surprise me if certain things did not get propagated through to the WebBrowser control in such a set-up–the PageBrowser is probably not expecting overly-dynamic controls within it (just a guess).
Having said that, what is the purpose of putting the WebBrowser control within the PageBrowser? Is there a way to have the WebBrowser control access a different URL based on the @device? If it is always accessing the same MCE instance, maybe just move it from the page you’re using in the PageBrowser to the same page as the PageBrowser (if that makes sense)? That is basically how mine is set up – I have the WebBrowser control in the top part of the page and the PageBrowser` for the keyboard control in the bottom part (you can kind-of see that in the picture in the first post).
Thanks, I suspect bug as well - specifically with Android browser - as it seems to work fine in the builder simulation but not on the tablet. Unfortunately, seems like work-around is the only clear option - not sure if there is a way to force android to use a different browser though THR app…
Looking into this a little further, I suspect issue is with “Android System Webview”, or THR handling of commands passed to webview. I’ve updated to latest version of webview with no change, also tried eliminating pagebrowser with no change.
I should note that I am using a scrollviewer - with the pagebrowser embedded within the scrollviewer and webbrowser embedded within the page referenced by pagebrowser. This leads me to believe issue is specifically with scrollviewer (since it doesnt work in scrollviewer regardless of whether pagebrowser is used or not, but DOES work normally in tab implementation or when opening xmal directly.
Not sure how to work around any of this though with out major tear-up of what I’ve already spent a lot of time working on…
It sure sounds like the scrollviewer is causing the problem, based on what you describe (I haven’t used that control much myself, so I’m not overly familiar with any quirks). Unfortunately, I don’t have a suggestion that doesn’t involve what I’m guessing is a lot of rework on your interface.