IR 8.03 now beta testing

[Capn Trips]

WHen I wrote SUCCESS that meant that I had indeed successfully downloaded from my remote. I tested with a RS 15-2117 and it got it all right (standard 2K EEPROM).

I checked earlier and I have UHCI.

[3FG]

Capn Trips,
Thanks for that good news!

I've modified the instructions, so I hope others won't have to work through the stuff you did. Thank you for your patience.

[mathdon]

I'm trying to test this new beta out but am running into issues. First, when I edit a learned signal or try to add one, the Pronto radio button is not selectable. Secondly, when I look at a learned signal, it's says "Analyzer: Not available" and "N/A" on the IRP form line.

These symptoms all mean that ExchangeIR.dll has not been loaded. I presume you have this in the same folder as IR.exe, so it appears to be the same issue that Calisoto encountered with IRScope, reported on this page. He also found the solution (same page):

I have found that, in order to load all the dlls, the Microsoft C++ Runtime Library 2008 vcredist_x86.exe is required.

I have now tweaked the ExchangeIR code so that it will compile under MinGW g++. I have posted this compilation as version 0.05a.

Rob, could you please replace the ExchangeIR.dll included with IR 8.03 Beta 5 with this revised one on your work computer and let me know if that now works.
_________________
Graham

[The Robman]

I've tested IR 8.03 Beta5 at home and here are the results:

1) Upload and download using a 2k EEPROM works fine.
2) Download from a 1k EEPROM remote works, but IR thinks there is 2k of data. I didn't try an upload (for obvious reasons).
3) As expected, it doesn't work with a 4k EEPROM remote.
4) Verified that pasting in a learned signal using Pronto hex works (this will be a very useful feature).
5) IRP is displaying, so ExchangeIR is loading ok and I didn't have to do anything or load anything to make it work (on Vista 64).
6) Verified that Pronto export still works.

A feature request for the future:
I think it would be great if the UEI/Pronto radio button actually switched the code that's displayed in the Data box from UEI format to Pronto format. This UI would be much more user friendly than using the export feature when someone just needs one quick sample of Pronto hex.

[mathdon]

Thanks, Rob, but I would still like to know if ExchangeIR v0.05a solves the issues you were having with your work computer. I don't want to post a final version that requires someone to fetch and install a Microsoft redistributable, neither do I want to have to include it as part of the distribution package.
______________
Graham

[The Robman]

Thanks, Rob, but I would still like to know if ExchangeIR v0.05a solves the issues you were having with your work computer.

I missed that, I think you posted it while I was posting my post. I'll test and report back.

[The Robman]

Good news, I tested it and can confirm it works. Thanks Graham.

[mathdon]

IR 8.03 Beta 6 posted

I have now posted IR 8.03 Beta 6. This adds two new options on the Advanced menu.

A feature request for the future:
I think it would be great if the UEI/Pronto radio button actually switched the code that's displayed in the Data box from UEI format to Pronto format. This UI would be much more user friendly than using the export feature when someone just needs one quick sample of Pronto hex.

I feel that this would not be everyone's preferred mode of operation. I found in testing that I tended to paste the data into the Data box and then select the format (UEI or Pronto) corresponding to that data. So I have made it an Advanced option. If Active Pronto Switch is checked then the radio buttons work as Rob suggests. This means, of course, that you need to select the correct button before pasting the data, otherwise it will attempt, and fail, to convert to the new format data that is already in that format. By default, Active Pronto Switch is unchecked.

The other new option is IRP Data Format. This enables you to choose whether the data values in the IRP analysis of the signal are given in binary, quaternary (base 4) or hex.

Near the start of this thread, Rob wrote

I'm trying to test this new beta out but am running into issues. First, when I edit a learned signal or try to add one, the Pronto radio button is not selectable. Secondly, when I look at a learned signal, it's says "Analyzer: Not available" and "N/A" on the IRP form line.

Am I doing something wrong?

This should no longer happen. It was due to the way ExchangeIR.dll was compiled. This Beta includes ExchangeIR.dll v0.06, which avoids that issue.
________________
Graham

[The Robman]

A feature request for the future:
I think it would be great if the UEI/Pronto radio button actually switched the code that's displayed in the Data box from UEI format to Pronto format. This UI would be much more user friendly than using the export feature when someone just needs one quick sample of Pronto hex.

I feel that this would not be everyone's preferred mode of operation. I found in testing that I tended to paste the data into the Data box and then select the format (UEI or Pronto) corresponding to that data. So I have made it an Advanced option. If Active Pronto Switch is checked then the radio buttons work as Rob suggests. This means, of course, that you need to select the correct button before pasting the data, otherwise it will attempt, and fail, to convert to the new format data that is already in that format. By default, Active Pronto Switch is unchecked.

Thanks for adding this Graham, I appreciate it.

I have a suggestion that might make the process a little smoother, eliminating the need for the advanced switch.

How about, if the hex code in the box comes from the learned signal that's already in the EEPROM memory, changing the radio button selection should change what's in the box, **BUT** if the code in the box was pasted there by the user, changing the radio button does *NOT* change what's in the box, but instead changes how IR will interpret the code. How does that sound?

[mathdon]

How about, if the hex code in the box comes from the learned signal that's already in the EEPROM memory, changing the radio button selection should change what's in the box, **BUT** if the code in the box was pasted there by the user, changing the radio button does *NOT* change what's in the box, but instead changes how IR will interpret the code. How does that sound?

Interesting! I rather assumed you wanted to be able to use this as a converter, without ever saving the signal to EEPROM. Since I've done it so that it can be used that way (press Add, select the format to be converted, paste, switch format, copy it and then Cancel) I would prefer to leave it as it is so as to provide this flexibility for anyone who wants to use it. The setting of Active Pronto Switch is, of course, preserved in the registry between invocations, just as with all other options so I don't see that having the switch option is any disadvantage.
________________
Graham

[The Robman]

I want to be able to select a learned signal and get the Pronto hex for it, so I can provide it to someone who needs the signal in that format. So, I would select a learned signal, click EDIT, then change the radio button to Pronto and cut & paste the resulting code.

If someone is using the ADD button, I would assume that they want to add the code to their remote, so in this case if they get the sequence wrong, they're going to have to start over. So my preference would be, when the user uses the ADD button, to let them change the radio button even after they have pasted the code.

Likewise, if they EDIT an existing code, then replace the displayed code with something else, I would assume that they want to update their learned signal with something that they found on the web, so again my preference would be to let them paste the code and then change the radio button afterwards if necessary.

Whereas pronto hex can be found posted all over the web, we almost never post codes in the raw UEI learned format anywhere, so I don't see much use for using this feature as a "converter" the way you described.

I can certainly live with the feature the way you've programmed it, because I will set the advanced setting and will get what I want from it. But I think it would be more user-friendly if you made the minor adjustments that I suggested.

[mathdon]

I have left the option, so that if Active Pronto Switch is checked then it behaves as I previously described. It seems silly to remove it when it is already implemented and may be useful to someone - though I suspect you may disagree with me on this. But I have changed the behaviour when it is not checked to be what you described. To remove all ambiguity, this is as follows. If you press Edit then the buttons remain active, switching the displayed format, until you edit the display in any way and in either fomat. They then become passive, affecting only the interpretation of the display when OK is pressed. This will be in Beta 7.
_______________
Graham

[The Robman]

I was giving this some more thought yesterday and I've come up with an idea that you might think is even better.

When someone pastes a code into the learned box, how about having IR inspect the code to see whether it's UEI or Pronto code and then automatically set the radio button to match.

Then, once the code has been pasted, if the user changes the radio button, you could convert the code.

What do you think?

[mathdon]

When someone pastes a code into the learned box, how about having IR inspect the code to see whether it's UEI or Pronto code and then automatically set the radio button to match.

There are problems with this. You don't have to paste, you can enter or edit the values from the keyboard. The "on change" code runs after every keypress. If that has to determine the format it is likely to be read as invalid, and would display an error message, each time until the data entry is complete. At present the data is not interpreted until either OK or a radio button is pressed, so this is not a problem. It only becomes so if the signal has to be read "on change" rather than on some other distinct action. BTW the data format is irrelevant, spaces are ignored, so it is not as simple as seeing if the digits are in groups of 2 or 4 (and during manual entry they may well be other sizes until editing is complete). So I would prefer to leave things as they are.
________________
Graham

[The Robman]

That makes sense, let's leave it as it is then.