JP1 Remotes

[Wheelie4]

gfb107,

Thank, I relized my mistake and was editing as you posted.
_________________
Daryl

[johnsfine]

The "Device Button" field in a KeyMove in IR.EXE is a great convenience for those who understand what it is, but as you found it can be a source of confusion.

It doesn't represent anything that is actually part of the KeyMove (as stored in the remote). A KeyMove really consists of:
Bound device
Bound Key
Setup code = Device type and 4 digit number
Hex Cmd

The "Device Button" (when available) is just a convenient shorthand for the setup code. Whether it's there or not has no effect on the actual KeyMove.

[Wheelie4]

[Wheelie4]

Well.

Robman, Mark, gfb107 and especially johnsfine. I've gone as far as I can untill my remote arrives Friday. I've got my IR file setup just the way I want it to work. Wether it will or not is left to be seen. I just want to say Thanks Alot, and that I appreciate all the help and patience with my impatience. It's muh appreciated.
_________________
Daryl

[Wheelie4]

I noticed the RDF's in the 8910ex1_1 zip is dated older than the ones in RDFs_for_IR_and_RM_Version_1.16 zip. Should I use the newer ones in the RDFs_for_IR_and_RM_Version_1.16 zip?

And just out of curiosity. Is there a way to use the info in RM's function tab to generate the hex code?
_________________
Daryl

[gfb107]

The information in RM's Functions tab "Hex" column should be the same as the information in KM's Functions tab "Hex" column, and can therefore be used in exactly the same way.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[johnsfine]

[Wheelie4]

Yes I was refering to a Pronto Hex. Still not use to JP1 terminology yet. I thought there might be a program that could take the protocol ID, OBC , EFC or Hex info from RM or KM and generate a Pronto Hex.
_________________
Daryl

[johnsfine]

There are at least the two programs I mentioned above (and a few similar programs at RC for a smaller set of protocols).

For MakeHex you:
1) Select an IRP file based on the protocol name (not ID) from RM.
2) Edit the IRP file to set the device number, subdevice number and the min and max desired OBC.
3) Use MakeHex (by command prompt, right click menu, or drag/drop, because it has no UI) to create a .hex file from the IRP file.
4) Open the .hex file in a text editor. It will contain Pronto Hex for each of the requested OBCs in numeric sequence.
5) Copy the Pronto Hex to where ever you needed it, in the process matching the OBC number to function names by manually refering back to RM's functions tab (for convenience in that step, RM lets you click to resort the entire functions sheet into OBC sequence).

That new Java version looks like it may reduce a little of the manual duplication of effort in the above (because it knows about function names) but it also doesn't yet pull data directly from RM.

[Wheelie4]

Kewl, thanks johnsfine.
_________________
Daryl

[Wheelie4]

Lets say you add a device to IR that automaticly adds keymoves. If you later delete that device are the keymoves deleted too or must they be deleted manually?

There's no harm in leaving the remote connected to the PC over the weekend is it?
_________________
Daryl

[johnsfine]

[Wheelie4]

[johnsfine]

If "duplicate" means what I'd expect it to mean, that would be a new bug, not the "flaw" I was refering to.

If you readd a device and the new device includes a KeyMove whose bound device and bound key matches an existing KeyMove, that new KeyMove should replace the old one so you get no duplicate.

If some previous version of an upgrade included a KeyMove and you replace that upgrade with a new version that doesn't include any KeyMove on that specific bound device/key, then the old KeyMove is retained (that's the flaw) but there still is no duplicate.

[The Robman]