RMIR: Prototype IR function in RM

[vickyg2003]

Dissociation of key moves from device upgrades

I have just made a change that should meet this need, if I understand the need correctly. If you change the device type or setup code for some button on the Device Buttons panel and the current values refer to a device upgrade that contains key moves, then you are asked if you want to preserve them. If you do then the preserved key moves will appear on the Key Moves tab (provided, of course, that the new values are not another upgrade).

If this is satisfactory then it will appear in the next release.

That's a first STEP, but not completely there. I still believe in the value of being able to DELETE an upgrade (not merely DEASSIGN it from a Device button) without deleting the associated KeyMoves (and/or Protocol upgrade)

Oh yes, we need to be able to delete the device upgrade and leave the keymoves and protocol there.

RM allows you to setup your equipment just the way you want it, with all your shift keys and xShift keys where you want them. This is a huge reason to create upgrades for equipment that already had good support with a built in setup code. I don't want to setup keymoves by hand, over and over again. Its so tedious to do it that way. I love that I can drop in my upgrade to get all my keymoves and adjust the way the protocol works all in one click. and then just delete the device upgrade to free up upgrade space.

It was that use of RM that made me an RM user and started me down the road of creating upgrades.

IF there is one thing we want/need to encourage everyone to do is to create upgrades for their equipment.

[gfb107]

RM allows you to setup your equipment just the way you want it, with all your shift keys and xShift keys where you want them. This is a huge reason to create upgrades for equipment that already had good support with a built in setup code. I don't want to setup keymoves by hand, over and over again. Its so tedious to do it that way. I love that I can drop in my upgrade to get all my keymoves and adjust the way the protocol works all in one click. and then just delete the protocol to free up keymove space.

It was that use of RM that made me an RM user and started me down the road of creating upgrades.

IF there is one thing we want/need to encourage everyone to do is to create upgrades for their equipment.

I understand why you find it appealing to install a device upgrade and then delete it in order to get all the associated keymoves installed in one fell swoop. I certainly don't want to you to have to recreate all those keymoves by hand. My objection is that you are doing it this way not because you actually want to install the device upgrade, but because you want the side effects that are the result of how IR has implemented device upgrade install and delete.

Imagine telling a new user the following:

1. Install the device upgrade
2. Delete the device upgrade
3. Upload to your remote
4. You've just changed how you remote works. Isn't that great!

That makes no sense! Why do something, then immediately undo it and expect to have something different than what you started with? Do you see my point?

We need another way to get the keymoves from a device upgrade installed that doesn't involve installing the entire upgrade and then deleting it. Maybe adding an import button to the keymoves tab. You then select the device upgrade from which you want to import keymoves.
It will launch a dialog of some sort allowing you to select which assignments to import as keymoves, kind of like how you can import external functions in RM.

Not sure exactly how this would look, but it would be possible to select/deselect all the assignments that would not usually create keymoves as a group. The same for all the assignments that would normally create keymoves. These are probably the ones that would be initially selected.
There would also be 'select all' and 'select none'
There would be a way to edit existing assignments, as well as create new ones. Probably not a way to edit or create new functions, and certainly not a way to tweak protocol parameters. For that you edit the device upgrade.

Once you're happy with the selected assignments, you press OK and Presto! all the selected assignments get imported as keymoves.

I am not saying that we should always delete all associated keymoves when an upgrade is deleted. That's what happens today. We need to give users control over that.

[The Robman]

RMIR is taking over. You can get to RM by opening a .rmdu or (KM) .txt file, or by File > New > Device Upgrade

I hate to be a luddite, but this is a backwards step for me. My modus operandi just involves using RM and it is a bit of a pain having to go through RMIR, which I will use VERY infrequently.

Can we not have an additional shortcut to go directly to RM ?

Alan, you can create a shortcut that goes directly to RM, just like how we used to create a shortcut to go directly to RMIR.

To do this, first you need to find where the javaw.exe program is on your system. On mine it's here: C:\WINDOWS\system32\javaw.exe

Then you need to format a shortcut like this...

C:\WINDOWS\system32\javaw.exe -jar "C:\Documents and Settings\qcpi429\My Documents\abstract\RM files\RemoteMaster.jar" -rm

[vickyg2003]

We need another way to get the keymoves from a device upgrade installed that doesn't involve installing the entire upgrade and then deleting it. Maybe adding an import button to the keymoves tab. You then select the device upgrade from which you want to import keymoves.
It will launch a dialog of some sort allowing you to select which assignments to import as keymoves, kind of like how you can import external functions in RM.

Well yes, both IR and RMIR now know what devices are in the remote, perhaps when a user goes to load a device, if the device is has the same id as one of the built-in devices, a question could be asked, is this a keymove-only load?

[gfb107]

RMIR is taking over. You can get to RM by opening a .rmdu or (KM) .txt file, or by File > New > Device Upgrade

I hate to be a luddite, but this is a backwards step for me. My modus operandi just involves using RM and it is a bit of a pain having to go through RMIR, which I will use VERY infrequently.

Can we not have an additional shortcut to go directly to RM ?

Alan, you can create a shortcut that goes directly to RM, just like how we used to create a shortcut to go directly to RMIR.

To do this, first you need to find where the javaw.exe program is on your system. On mine it's here: C:\WINDOWS\system32\javaw.exe

Then you need to format a shortcut like this...

C:\WINDOWS\system32\javaw.exe -jar "C:\Documents and Settings\qcpi429\My Documents\abstract\RM files\RemoteMaster.jar" -rm

If you installed preview4, and ran Setup.vbs, this should have already been done for you. There is a bug when running Setup.vbs on 64-bit Windows, but I'll have a fix for that in the next preview. Or you can get the fixed Setup.vbs. The fix isn't fully yet tested, as I don't have 64-bit Windows, but I feel pretty confident it will work.

[The Robman]

I've been watching your discussions with Capn Trips, so I knew it wasn't working properly yet, which is why I suggested that Alan create it manually.

[vickyg2003]

Then you need to format a shortcut like this...

C:\WINDOWS\system32\javaw.exe -jar "C:\Documents and Settings\qcpi429\My Documents\abstract\RM files\RemoteMaster.jar" -rm

Thank you. I didn't see the shortcut, but I've now created a shortcut based on this information, in my JP1tools folder and I'm very happy.

[mathdon]

Vicky, perhaps I don't understand what you mean by "little markers". I thought you meant the tabs at the top of the screen, but here is New for the URC-10820:

Everything seems in order to me.

Ah you want a technical name. I guess that would be device table.

Do a file new of the URC-10820 in IR and RMIR,

Look at the value in EE00 where the device tables should be.

RMIR
EE00 = FF FF FF FF FF FF

IR
EE00 = EE 04 EE 04 00 00

I'm pretty sure the empty device table is a requirement of the remote.

As for the learned marker, I was looking at the wrong address its there the little 0 that is in the last byte before the learning section.

Ah, now I know what you mean. That behaviour is a consequence of a bug that I have fixed (for a different reason) but it didn't make it into the last issued version. I've just checked URC-10820 "New" with my development version, it is OK.

[Capn Trips]

Regardless, I appreciate your herculean efforts and will continue to download and use every new iteration of RMIR, and will continue to provide my thoughts on it (at least until Rob bans me to Jim Hammel and Elliot Axel-land)

Don't worry Capn, you ain't goin' nowhere. And I think you're referring to James Gammel!

Gammel-Hammel. What's the difference? You still failed to heed his advice on NOT advising folks to send random IR codes to some obscure obsolete obsequious Pioneer LaserDisc player! And he was going to be NO PARTY to that sort of shenanigan!

[mathdon]

Dissociation of key moves from device upgrades

I have just made a change that should meet this need, if I understand the need correctly. If you change the device type or setup code for some button on the Device Buttons panel and the current values refer to a device upgrade that contains key moves, then you are asked if you want to preserve them. If you do then the preserved key moves will appear on the Key Moves tab (provided, of course, that the new values are not another upgrade).

If this is satisfactory then it will appear in the next release.

That's a first STEP, but not completely there. I still believe in the value of being able to DELETE an upgrade (not merely DEASSIGN it from a Device button) without deleting the associated KeyMoves (and/or Protocol upgrade)

I thought it went without saying that once you have changed the device button assignment to another device and retained the key moves, you can then delete the device upgrade. The key moves are now attached to the new device and so remain unaffected.

[The Robman]

Regardless, I appreciate your herculean efforts and will continue to download and use every new iteration of RMIR, and will continue to provide my thoughts on it (at least until Rob bans me to Jim Hammel and Elliot Axel-land)

Don't worry Capn, you ain't goin' nowhere. And I think you're referring to James Gammel!

Gammel-Hammel. What's the difference? You still failed to heed his advice on NOT advising folks to send random IR codes to some obscure obsolete obsequious Pioneer LaserDisc player! And he was going to be NO PARTY to that sort of shenanigan!

Just because I'm not about to send you into exile, doesn't mean I can't still send you to the Hall of Shame!

[xnappo]

We need another way to get the keymoves from a device upgrade installed that doesn't involve installing the entire upgrade and then deleting it. Maybe adding an import button to the keymoves tab. You then select the device upgrade from which you want to import keymoves.
It will launch a dialog of some sort allowing you to select which assignments to import as keymoves, kind of like how you can import external functions in RM.

Well yes, both IR and RMIR now know what devices are in the remote, perhaps when a user goes to load a device, if the device is has the same id as one of the built-in devices, a question could be asked, is this a keymove-only load?

I like that idea - makes a lot of sense.

xnappo

[vickyg2003]

We need another way to get the keymoves from a device upgrade installed that doesn't involve installing the entire upgrade and then deleting it. Maybe adding an import button to the keymoves tab. You then select the device upgrade from which you want to import keymoves.
It will launch a dialog of some sort allowing you to select which assignments to import as keymoves, kind of like how you can import external functions in RM.

Well yes, both IR and RMIR now know what devices are in the remote, perhaps when a user goes to load a device, if the device is has the same id as one of the built-in devices, a question could be asked, is this a keymove-only load?

I like that idea - makes a lot of sense.

xnappo

Deleting a device could automatically delete the keymoves if there was no built in device of the same device id, and could ask if there was also a built in device with the same device id. Left over keymoves can cause problems for occasional users who are changing out their equipment . Although I really hate it when IR makes any changes without my permission.

[The Robman]

Personally, I don't want any program deleting anything without asking first.

[xnappo]

Personally, I don't want any program deleting anything without asking first.

Agreed.

xnappo