New Versions of InputDeviceMapper of LiveDriveIR (1 Viewer)

[kaburke]

From now on new releases will be announced here. This thread will be dedicated to technial problems/questions.

If people have some spare time, I would appreciate feedback on the plugins I wrote described below (both their usefulness and how they're written).

Version 0.2 of InputDeviceMapper and version 0.2 of LiveDriveIR have now been uploaded.

InputDeviceMapper has had some serious work done to it. There have been some feature upgrades, a reworked plugin system, and some code clean up. See the changelog for more details.

The only change to LiveDriveIR was to make it compatible with the new InputDeviceMapper.

The plugins have been uploaded as patches: InputDeviceMapper, LiveDriveIR

 

[Anonymous]

hi,

first of a all great work !!!

At first look your code seems to be quite clear - you could perhaps have a look here, how naming conventions etc. are in MP
http://nolanparty.com/mediaportal.sourceforge.net/phpBB2/viewtopic.php?t=2631

some remarks:
- it would be nice if your plugins would be called DevicePlugins or sth. like this so that you can't be confused with "normal" plugins
- I think version management for DevicePlugins would be useful if something is changed in your InputDeviceMapper
- I think it would be better if the mapping would be linked with a control so that you choose DevicePlugin first and then the mapping - not you can see all mappings all the time - perhaps you could first choose Plugin then show setup dialog with a tabControl where at 1st tab general setup-form, 2nd tab mapping stuff, (perhaps 3rd tab control testing area)
- at the moment if you add a new mapping it is really bothering to enter a name, perhaps you could add default name or name=action or something else?!
- I think it would be easier if you want to add a lot of mappings that all available commands are listed in a listview and you could select the action you want to learn (perhaps you could have a look on my (old) WinLirc AddOn I posted a few days ago in patch section - I did somthing like that)
- small bug: if you have no plugin selected and then click configure plugins -> configure you get an exception

but don't get me wrong this should not be criticism - just a few ideas to improve this great project ;-)


P.S.:
As promised I coded the NewWinLirc as a plugin using your InputDeviceMapper 2.0. You can find it here:
https://sourceforge.net/tracker/index.php?func=detail&aid=1160983&group_id=107397&atid=647927

keans

 

[kaburke]

Thanks for you feedback; I appreciate you taking the time to try the plugins, and even put them to use.

- it would be nice if your plugins would be called DevicePlugins or sth. like this so that you can't be confused with "normal" plugins

Good idea. It will be done in InputDeviceMappings v0.3.

- I think version management for DevicePlugins would be useful if something is changed in your InputDeviceMapper

This is certainly something I'll consider, but seeing as the only part of InputDeviceMapper that the device plugins "see" are the interfaces and the handle() method, they are isolated from any internal changes. From now on I am going to make a point not to change the interfaces or handle() method definitions, nor to place more responsibility for anything on the device plugins, in order to ensure backward compatibility. Having said that, if ever I decide I have to make such a change, I will of course have to implement some form of versioning.

- I think it would be better if the mapping would be linked with a control so that you choose DevicePlugin first and then the mapping - not you can see all mappings all the time - perhaps you could first choose Plugin then show setup dialog with a tabControl where at 1st tab general setup-form, 2nd tab mapping stuff, (perhaps 3rd tab control testing area)

The testing area is an interesting idea. It would actually have simplified my development if I hadn't had to keep fliping back to MediaPortal to test the mappings! I will try to develop something along those lines, though I'm not entirely clear yet how the testing would work (simply printing out the mapped Action or keystroke seems pedantic, but may be sufficient).

As to selecting a Device Plugin first and grouping all mappings in a per Device manner, I purposely did not do that. I thought it could be useful to have a Profile that could contain mappings from several different Device Plugins (e.g., a Profile that allows you to use both a gamepad and a remote at the same time - perhaps the remote when you're in the living room and the gamepad when you're sitting at your computer).

- at the moment if you add a new mapping it is really bothering to enter a name, perhaps you could add default name or name=action or something else?!

I agree. I was bothering me, too, but I rationalized it away by saying that, usually, this would only be a one-time-setup. Once you have the mappings configured (a matter of say an hour or whatever), you're not likely to go back and redo it ever again - indeed you probably won't ever come back to the config screen. But, seeing as you pointed it out, I guess I shouldn't have been lazy, and done something about it.

In InputDeviceMappings v0.3, if the Name field is left blank, I will generate a Name. (Incidentally, in InputDeviceMappings v0.2 there wasn't anything stopping you from leaving the Name field blank - your mapping simply wouldn't have had a name.)

- I think it would be easier if you want to add a lot of mappings that all available commands are listed in a listview and you could select the action you want to learn (perhaps you could have a look on my (old) WinLirc AddOn I posted a few days ago in patch section - I did somthing like that)

I'm not quite sure what you mean, so I'll take a look at your WinLirc AddOn. I agree that learning the actions one at a time is quite tedious, so any ideas on improving that process are welcome. As I said, I'll have a look at your AddOn and see what I come up with.

- small bug: if you have no plugin selected and then click configure plugins -> configure you get an exception

My apologies. It's rather embarassing that I missed such a simple bug. It's fixed in InputDeviceMappings v0.3.

Incidentally, I'm going to post InputDeviceMappings v0.3 in the usual spot in about 30-60 minutes, once I have it packaged and the documents updated.

InputDeviceMappings v0.3 has been uploaded as a patch: InputDeviceMapper

 

[Anonymous]

Having said that, if ever I decide I have to make such a change, I will of course have to implement some form of versioning.

ok, that's true - it a exaggerated to build version system if nothing changes...

(simply printing out the mapped Action or keystroke seems pedantic, but may be sufficient).

yes, that would do - just the device which fired and the action event which is executed

As to selecting a Device Plugin first and grouping all mappings in a per Device manner, I purposely did not do that. I thought it could be useful to have a Profile that could contain mappings from several different Device Plugins (e.g., a Profile that allows you to use both a gamepad and a remote at the same time - perhaps the remote when you're in the living room and the gamepad when you're sitting at your computer).

ok, I see your point - I did not consider this concept. But I think that you program your IR for example once and your gamepad pad once and if both DevicePlugins are enabled the should both work in MediaPortal. So it is a question of design - so it works as it is and if you don't want to change it leave it how it is...

In InputDeviceMappings v0.3, if the Name field is left blank, I will generate a Name.

I would prefer if the generated name would already in the TextBox and you could change it if you want

I'm not quite sure what you mean, so I'll take a look at your WinLirc AddOn. I agree that learning the actions one at a time is quite tedious, so any ideas on improving that process are welcome. As I said, I'll have a look at your AddOn and see what I come up with.

I think there could be a problem with that if you keep the idea with Mapping different devices in one configuration :roll:

My apologies. It's rather embarassing that I missed such a simple bug. It's fixed in InputDeviceMappings v0.3.

sorry, but I got another one ;-) - in plugin configuration - if no plugin is selected and you double click on the white in the list (not on an item) there will be an exception

All in all good work - that is really fast progress 8)

keans

 

[MaceX]

cool plugin.

I just created a plugin to make use of my sapphire remote that came with my theatrix, and possibly other remotes that use a usb IR thing. I ran into a few problems though, I don't know if it's my plugin or InputDeviceMapper.

When I go to learn a command and press a button on my remote and then press a different button on the remote an exception is raised.

System.InvalidOperationException: Forms that are already visible cannot be displayed as a modal dialog. Set the form's visible property to false before calling showDialog.
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at InputDeviceMapper.InputDeviceMapperSetupForm.editMapping(String p_strPluginId, String p_strCode)
at InputDeviceMapper.InputDeviceMapperSetupForm.addNewEventMapping(String p_strPluginId, String p_strCode)
at InputDeviceMapper.InputDeviceEventMapper.handle(String p_strPluginId, String p_strCode)
at USBRemoteIR.USBRemoteWindow.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Also if I learn a command and press the same button twice I get this message.

'40320' is the code for the button I pressed and it's not assigned to any command.

"The code '40320' for plugin 'USBRemoteIR.USBRemoteIR' is already used by the '' command.

I found another small bug in the InputDeviceMapper. If you click in the white area in the list box and hit delete an exception is raised.

System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: index

One more thing.
I'm a little new to c#, is there a way to create a WndProc without creating a Form? Because the way I'm getting input from the remote is from the WM_INPUT message. I have the Form's visible property set to hidden after I call Show(), but it still shows up for about a millisecond.

 

[Anonymous]

hi,

When I go to learn a command and press a button on my remote and then press a different button on the remote an exception is raised.

I can't duplicate this exception?!

Also if I learn a command and press the same button twice I get this message.

'40320' is the code for the button I pressed and it's not assigned to any command.

I think this was the intention of the author to show an error if you try to use a button which is already in use...

I found another small bug in the InputDeviceMapper. If you click in the white area in the list box and hit delete an exception is raised.

hm, strange - it shows "No command has been selected" in my version

keans

 

[MaceX]

hi,

When I go to learn a command and press a button on my remote and then press a different button on the remote an exception is raised.

I can't duplicate this exception?!

Also if I learn a command and press the same button twice I get this message.

'40320' is the code for the button I pressed and it's not assigned to any command.

I think this was the intention of the author to show an error if you try to use a button which is already in use...

I found another small bug in the InputDeviceMapper. If you click in the white area in the list box and hit delete an exception is raised.

hm, strange - it shows "No command has been selected" in my version

keans

I don't know why you can't duplicate the first exception, after I click the learn command button and press a button on the remote and then press another button on the remote I get that exception.

I think this was the intention of the author to show an error if you try to use a button which is already in use...

Yeah, but it's not supposed to say a key is in use when it's not and reporting a null command.

hm, strange - it shows "No command has been selected" in my version

I meant the delete key, not the button.

 

[MaceX]

I recompiled the InputDeviceMapper source with some edits to fixed the above problems I've listed. I made it so it doesn't get input if the edit mapping window is visible. That seems to be the problem.

 

[MaceX]

OK here's my plugin. It works perfectly for me.

I don't know if it will work on other remotes that use the WM_INPUT message because I only have one remote, the one that came with my theatrix.

http://www.wtfhost.com/userfiles/mace/USBRemoteIR.rar

 

[kaburke]

Sorry I didn't reply sooner - I was busy this weekend and didn't get a chance to watch the posts.

When I go to learn a command and press a button on my remote and then press a different button on the remote an exception is raised.

When are you pushing the buttons? Are you pushing them both while the "Learn Command" window is showing?

I don't know why this could be happening (though it would help to have more information about the details, such as answers the the above questions). Unfortunely I don't have a USB IR dongle to try it out, but I will look at your source code and see if I can figure out how my code is misbehaving in relation to it.

Also if I learn a command and press the same button twice I get this message.

'40320' is the code for the button I pressed and it's not assigned to any command.

I'm not sure what you mean by "press the same button twice." Are you pushing the button twice while the "Learn Command" window is showing, or after it closes?

But, again, I'll look at the code.

I found another small bug in the InputDeviceMapper. If you click in the white area in the list box and hit delete an exception is raised.

Sorry - this was really stupid of me. It was a bug I introduced into the latest version. It will be fixed in InputDeviceMapper v0.4.

InputDeviceMapper v0.4 should be out soon - perhaps end of today. It will include some drastic (I hope) improvements in interface, particularly for creating new profiles/learning commands, as well as some bug fixes.