Reply to thread

Message: <blockquote data-quote="kaburke" data-source="post: 12938" data-attributes="member: 11818">I'm not sure what is happening. I looked over the code and all seems fine. Is there some way (through logging etc.) that you can pin down exectly where the exception is first being seen by InputDeviceMapper?I understand that this would be convenient, but it would go against the intended model for InputDeviceMapper. Indeed, the idea of mapping events to keystrokes goes againts the intended model, but (perhaps unfortunately) MediaPortal has certain limitations.Perhaps I should give a brief explanation of the intended model. PLEASE NOTE THAT THIS DISCUSSION IS IN NO WAY MEANT TO BE A CITICISM OF THE EXISTING/PAST/FUTURE MODEL OF MEDIAPORTAL. This is simply my opinion - it is not neccessarily correct, nor better than any other proposed model. Having said that....MediaPortal should not deal directly with user input. Rather it should be driven by events (let's call them Actions) that are triggered by a User Input layer (preferrably implemented as a plugin). All user input devices, be they keyboards, mice, remotes, etc, should pass their User Input Device events (e.g., keypress events) to this User Input layer, which would map said Input Device Events to a particular Action, and then fire that Action off to MediaPortal. This would separate MediaPortal from any particular control mechanism, allowing easy development of new user input interfaces.Now, in case it was not obvious, it was my intent that InputDeviceMapper be the described User Input Layer (not that I expect it to be adopted as an official part of MediaPortal - it was intended for my own use, and for the use of those who found it useful). Having said that, strictly speaking, InputDeviceMapper should not pass any keystrokes to MeadiPortal, only Actions. Hence, it would be inappropriate to import keystrokes from the Keymap file.Having said that, there are certain limitations. For better or worse MediaPortal does not operate strictly on Actions - some features can only be controlled by the keyboard (or, more strictly, by keypress events). In order to accomodate this, I allowed Input Device Events to be mapped to keystrokes.The end result... I'm not going to integrate the functionality to import the Keymap file into InputDeviceMapper, as I believe that it would be to much a departure from the intended model. However, I would be willing to create a separate helper/utility application that takes a keymap file as input and generates an InputDeviceMapper compatible UserInputMappings.xml file, if people are interested.I have decided to leave things the way they are for now, mainly because changing it would mean that I would have versioning issues (old plugins would not neccessarily work with the new InputDeviceMapper). If you want to be able to disable the plugin, without it having a configuration screen, implement IConfigurableInputDevicePlugin but display a message indicating there is nothing to configure when ShowPlugin() is called.</blockquote>

Verification