The Media Center Sandbox

The Element ShortCutHandler is documented as supporting events for the remote MoreInfo button using the label "Details", however, this doesn't work in practice. What do I need to do in order to hook this button?

 

Zakspeed

You can't and this by design.  It isn't in the ShortcutHandlerCommand enumeration, and as far as I can tell, it's not referenced in the current SDK.  Where are you seeing this?

---

Scott Moore (Microsoft)

Hi,

I noticed the same thing in the RC1 MCE SDK (have to check again for RC2 release).. Quite a few shortcut keys including 'Details' were mentioned in the Docs (for shortcuthandler) - but threw errors when I tried to use them (XSD complained - and then MCML verifier refused to accept them).. 

The descriptions provided (such as 'details') also didn't make a whole lot of sense in the context of the MCE2005 remote/keyboard (ie no actual key marked 'details' etc) - so not sure if these were typos or referencing some new Vista remote we havent yet seen.

However - I do think allowing developers to handle the 'i' button is really important - as the user will expect to be able to use this button (as they do in the main UI)..

Niall

 

I would completely agree - I hadn't got this far yet, but this is a real issue for me.  I have existing applications that take advantage of the "more.." functionality of MCE2005 and I wanted to be able to improve on this in Vista.

Andrew

We originally allowed you to handle the More Info button on the remote (that's why you see it in the docs), but then we had to remove it.  The reason is that pressing more info for certain types of addins brings up a context menu with (among other things) a button to display security information about the current add-in.  If we allowed add-ins to handle this button, then they could spoof the context menu and display bogus security information.

---

Scott Moore (Microsoft)

Scott,

I appreciate the reasoning behind this - but perhaps the implementation could have been done in a more addin friendly way. this solution is more like using a stick of dynamite to catch a sardine.. 8)..

I'm not sure what options were discussed there (and what were not implemented due to time/budget issues) - but a few alternatives that would have been nicer -

1) Use the 'Program Library Options' settings to allow the user to enable/disable use of this button (you already have an option 'Hide Security Warnings' - so this is a small step further).

2) Show a warning dialog the first time the addin tries to handle this button - which allows the user to decide on a 'per addin' basis on whether to allow/deny permission to use this button. This would also include an 'always allow' checkbox so this could be remembered for future use. The dialog could also state that it 'could' be a security risk etc - and lets the user decide.

3) Provide some sort of callback function which allows the user to supply a list of Context menu buttons (similar to how buttons are supplied for the showmcedialog function). With this solution you could ensure the security info button was placed as the top (or default) menu option.

Option 2 would probably be my preference.. (as it caters for power users - and beginners who might not be able to  find/understand the program settings menu).

Niall

 

Actually one other possibly (code/codeless MCML friendly).

Add an additional handler which results in a context menu being shown - <infokeyhandler>.  (where a Security Info button is placed on top).

This could allow the developer to supply an ArrayListDataSet/IList of Commands (much like the Source property on a Repeater). The description field from each Command could be used for the text of the buttons on the menu - and then developers could handle the menu presses via .Invoked event on the command.

Niall

 

 

I agree that we could have provided better ways for add-ins to integrate with the context menu, but unfortunately due to time/budget/yada yada what we have today is where we are :-/

I'll certainly make sure that it's noted as a feature request for vNext though

---

Scott Moore (Microsoft)

Okay, appreciate we are where we are - any thoughts on how to get around this issue we find ourselves in?

I had a look under MCE2005 at intercepting the WM_INPUT messages for the remote so I could distinguish between keypresses on the remote vs. the keyboard for a better input experience in HTML extensibility apps.  Unfortunately ehshell filters out the WM_INPUT messages before they get to the app - the code worked perfectly outside of Media Center, but once inside the messages never appeared.

I decided to give up at that point, but a solution I thought of was to have an exe running outside of Media Center getting remote keypresses, and communicating with MCE via .NET Remoting, which would allow the interception of any key on the remote (I think) - you could then construct your own context menus (painful but better than nothing).

Any advances on this idea?

Cheers,
Andrew

For what it's worth, our studies have shown that the large majority of users typically don't discover (or use) the context menus in Media Center.  Any functionality that you put there may as well not exist for them.

If it's really that important to your application, then I would recommend just adding a more info button somewhere in your UI, and know that this is on our radar for something we'd like to do in the next version.

I would strongly recommend against trying to come up with hacks to circumvent this, as they would be very likely to interfere with normal input processing, very likely break in future versions, and also likely not worth the trouble it takes to figure them out/implement them given the first paragraph above.

---

Scott Moore (Microsoft)

I am surprised to find-out that there's no support for the 'i' button. I think it is the one button that any user intuitivly recognize as the "Other options" button. It would be very useful to be able to handle its keypresses.

I have some-sort of an information-screen in my application which users can access from anywhere in the app. Making it available as a short-cut via the 'i' button seemed like the obvious choice for it... Too bad it can't be done yet...

Scott:

We originally allowed you to handle the More Info button on the remote (that's why you see it in the docs), but then we had to remove it.  The reason is that pressing more info for certain types of addins brings up a context menu with (among other things) a button to display security information about the current add-in.  If we allowed add-ins to handle this button, then they could spoof the context menu and display bogus security information.

OK, I understood the reason behind it, and was gonna leave it alone... However ....

Check out the new Fox Sports plugin ... you allow that vendor to override the more info functionality .. why can't everyone else? 

Roy

Hi,

I see that it is not possible to intercept WM_INPUT messages from the inside because they are intercepted by media center.
What about WM_APPCOMMAND messages ? (which treat play, pause, stop, fast forward commands...) Is there a possibility to catch them inside the plugin ?

The problem is that the low level keyboard hook only works for arrows and numbers keys.

What about derivating the keyboard hook class from System.Windows.Forms.Form and overriding WndProc method ?

Thanks

I've got to admit that I was really hoping to be able to at least add to the 'i' button list, since I want to be able to offer users the ability to bring up more information about the music they are listening to and/or the videos they are watching.

Personally, I think we should be able to add elements to ALL of these detail windows - for DVD playback, video playback, picture playback etc. I want to add 'Dance To' to music so I can launch Ultrastar, I would like to provide IMDB details about the DVD you are watching directly WHILE watching the DVD (without skipping out) etc.

A background addin with the ability to add list elements would be fantastic - and should be an important new feature in vNext.

---

100 downloads a day for Yougle Vista - goin' allright!

Check out http://www.thedigitallifestyle.com/cs/Blogs/developer/default.aspx and http://www.push-a-button.com.au/products/mce

Andy,

I tried to design an external app implementing the NativeWindow class : I tried to assign the same MainWindowHandle as ehshell, but it makes ehshell and my app quit.

A workaround would be to make the addin register for receiving the remote control commands with the Win32 method "RegisterRawInputDevices", as explained in the following link :

http://msdn2.microsoft.com/en-us/library/ms867196.aspx

RAWINPUTDEVICE Rid[1];

Rid[0].usUsagePage = 0xFFBC;
Rid[0].usUsage = 0x88;
Rid[0].dwFlags = 0;

if (RegisterRawInputDevices(Rid, 1, sizeof(Rid[0])) == FALSE)
{
    ErrorExit();  // Add error-handling code here.
}