JP1 Remotes

The Robman wrote:

RMFolder will be 'C:\Users\Rob Crowe\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Remote Master'

Are the shortcuts in that folder?

xnappo

Yes, and now that I've taken a 2nd look, I can see the "Remote Master" folder under "All Programs" in the Start menu.

I've just built RMIR v1.99preview3

• Add support for notes on device buttons
• Add new protocols and translators
• Add draggable divider to RMs Buttons panel along the left edge of the Available Functions
• Replaced setup.bat with Setup.vbs for creating the Start Menu shortcuts and file associations.

gfb107 wrote:I've just built RMIR v1.99preview3

• Add support for notes on device buttons
• Add new protocols and translators
• Add draggable divider to RMs Buttons panel along the left edge of the Available Functions
• Replaced setup.bat with Setup.vbs for creating the Start Menu shortcuts and file associations.

Hi Greg thanks for all your hard work on RM and thanks for the updates. I have a request if it would not be to much work to add what I would like is the option to print the OBC that are assigned to a key. So on the key Map tab where we can print the the button and functions assigned to them it would be nice to also be able to print the functions OBC. This would help a lot when I am building remote macros and testing them with the IR WIDGET. I usually print the sheets out and write in the OBC so I can check the macros with the widget. It might also be nice to have a check box under options to turn this feature on or off if the person does not want it. So let me know what you think.

Thanks,
dolivas

I've just built RMIR v1.99preview4

• General Panel: default device button notes to description of assigned device upgrade, if there is one.
• Buttons/Layout tabs: limit display of function names to 20 characters, but show full name in hover help.
• Buttons tab: Move function popup menu down so previously assigned value is still visible.
• Layout Tab: Add dragable divider along right edge of remote image; image scales to divider position.

dolivas27 wrote: Hi Greg thanks for all your hard work on RM and thanks for the updates. I have a request if it would not be to much work to add what I would like is the option to print the OBC that are assigned to a key. So on the key Map tab where we can print the the button and functions assigned to them it would be nice to also be able to print the functions OBC. This would help a lot when I am building remote macros and testing them with the IR WIDGET. I usually print the sheets out and write in the OBC so I can check the macros with the widget. It might also be nice to have a check box under options to turn this feature on or off if the person does not want it. So let me know what you think.

Thanks,
dolivas

Maybe it makes more sense to add print support to the Functions tab, and possibly others as well

I like all of these changes, Greg. Very nice. Now images can be used that have more detail (although that's a separate project to update remote images and their associated maps)

How about in the Device Manager pop-up (i.e. RemoteMaster invoked from RMIR) activating the "Minimize", and"Maximize/Minimize" functions in the top bar - or at least double-click the header bar to maximize/restore.

I know that you can resize by dragging an edge or corner, but this makes it "nicer".

Greg, I have committed three changes, all bugfixes, to the SVN repository. These fix the following bugs:

1. If the same Manual Settings protocol was used in two Device Upgrades, RMIR would collapse.

2. The "Labels+" keyword was not recognised by RMIR in the General section of an RDF.

3. If an RDF set up Soft Devices but not Labels, the Device Buttons panel would attempt to create a Labels column instead of a Sequence column, causing RMIR to collapse.

My .ir files now all read into RMIR, but it garbles Key Moves that move a key (which have a 1-byte value) and turns them into (inequivalent) Key Moves that specify a hex command (which have a 2-byte value). I see from the code that this is done quite deliberately by appending the EFC of the 1-byte value and incrementing the length byte. I know that 1-byte commands need to be expressed as 2-byte commands in the URC-7781 and that this is commonly done by appending the EFC, but it is wrong to do this when reading the EEPROM or a .ir file - it has already been done where necessary, and its purpose is to make a distinction between 1-byte values that are key codes and 2-byte values that are hex commands (even if only one of the bytes is sent).

IR.exe handles this correctly. I don't understand why RMIR is doing what it does. I can certainly check what IR.exe is doing and attempt to make RMIR do the same thing, but you may prefer to do it yourself in case I mess something else up in the process.

I have committed five more bugfixes to the SVN repository. Three of these concern the device type of upgrades, the reading of the Fixed Data section of an RDF and the handling of upgrades with the Mitsubishi 740 processor, all of which could cause RMIR to collapse. The fourth prevented RMIR from reading the Pause Parameters entry in an RDF. The fifth made a consequential change that was overlooked when the Notes column was added to the Device Buttons panel.

Hi Greg the print support on all the tabs sounds great another option I would like to see is on the Buttons / Layout tab is to have a button to remove all. I have found when I want to change remotes sometime the assigned buttons are moved to phantom key so just feel it would be easier to clear everything and start over.

Thanks,
dolivas27

Thanks for the help Graham. I'll take a look at the key code key moves.

BTW, you don't have to inform me when you've submitted changes. I am automatically informed whenever anything is checked in. However, feel free to announce what you've done if you want everyone else to know. I will attribute your changes to you in the change log.

I have been announcing the bugfixes I've made so that others can see that things are getting fixed, and that RMIR may be worth trying again if, like me, they have tried it in the past and it collapsed on them or they experienced a problem that it seems I may have corrected. For instance, I'm sure I saw a recent post from someone having problems using RMIR with a remote with a Mits 740 processor. I can't find the post, but if they look here they will see that may be corrected in the next beta version. I'm not concerned about getting credit for the fixes, just about letting people know things are getting done.

Greg, I have a question for you about the philosophy of RMIR - what should it do when importing an invalid .ir file? I came across this today with a .ir file that had a device upgrade with a PID that was neither built-in nor an upgrade. RMIR simply locked up - not even a Remotemaster.err file to show what was happening. I didn't know there was a problem with the .ir file, so I thought it was yet another bug. Well, in a way, to me, it is. I would rather it opened and showed something, even if what it showed was invalid or inconsistent. So I have made changes (not committed to SVN) to make it create an esssentially empty Manual Settings protocol, which allows it to open.

What is your view on such situations?

I want RMIR to detect that the file is invalid and put up a message indicating that the file is invalid, and what about it is invalid. It is OK for the invalid file to be rejected in its entirety.

I do NOT want RMIR to fail/crash silently.
I do NOT want RMIR to silently modify the invalid file just so it can continue running, leaving the user unaware of the issue.

If it is OK for RMIR to try to accept the valid portions of the file, as long as there is an explicit and meaningful message displayed to the user about what is being ignored/discarded/modified/added, but I would not put a lot of effort into that.

gfb107 wrote:it is OK for RMIR to try to accept the valid portions of the file, as long as there is an explicit and meaningful message displayed to the user about what is being ignored/discarded/modified/added

That would be much my preferred option, as I would like RMIR to be able to be used to fix the problem, just as IR.exe can be. Otherwise, I agree with everything you said. In particular I too have a strong dislike of "silent corrections", in case they happen to be mis-corrections.

I'll leave this aside for the time being until I understand the operation of RMIR better. There are other, simpler, things to be done with valid files before worrying too much about how to handle invalid ones.