Page 2 of 2

Posted: Sun Sep 13, 2015 1:58 am
by Barf
The Robman wrote:He's looking for something similar to how IR and RMIR let u save a file in a format that keeps all your comments, etc. Even though that data doesn't make it into the raw data that gets loaded into your remote. So, in this case, if he's already done all the work of mapping codes, etc he wants to save it in a format that can be re-opened using IRS and have it look the same as when he saved it.
Ok, it is clear now. Thank you. Sorry I did not get it earlier. What happens is that if "Raw" or "Pronto Hex" is selected on the export/Girr pane, AND the signal is not renderable (like an unknown protocol) the exporter gives up completely. This is not a very good situation, and something I will fix. Without this fix, you can just de-select "Raw" and "Pronto Hex", and it should work as you expect, including preserving the commands. Please let me know if this is the case or not.
The Robman wrote:Regarding the other stuff with protocols and executors, would it be possible (or practical) to have some sort of .ini file for IRS that maps the various names in protocols.ini to the names in IRP that IRS uses?
No, the problem of mapping protocol names is harder than that (see my comments on NEC1), and it is just one of several problems.
ncoig wrote:Alas, exporting my information to any format yields a file that, while I can read it and see the data's there, IRS barfs (couldn't resist) on the import and fails entirely.
Please upload one such to the diagnostic area, and describe in detail what you did. If a program generates something it cannot read, that is bad.

Bengt

Posted: Sun Sep 13, 2015 2:44 am
by Barf
Try this testversion to see if it solves the problem. If "Raw" or "Pronto Hex" is selected, and the signal cannot be rendered, it still does all the other stuff, including the parameters.

(Overwrite existing IrScrutinizer.jar (or IrScrutinizer-jar-with-dependencies.jar) with this file.)

Posted: Sun Sep 13, 2015 10:45 am
by Barf
ncoig wrote:... there isn't an "IMPORT ANYMOTE" function.
While I am pretty happy about the procedure for adding export formats (just add to the text file exportformats.xml), the same is not true for the import formats.

However, it would be a rather simple exercise to write a little stand-alone proggie for translating Anymote files to girr, using for example a language like Python (or Visual Basic, or ...). Would that be helpful?

Posted: Wed Sep 16, 2015 12:22 am
by ncoig
Barf wrote:Ok, it is clear now. Thank you. Sorry I did not get it earlier. What happens is that if "Raw" or "Pronto Hex" is selected on the export/Girr pane, AND the signal is not renderable (like an unknown protocol) the exporter gives up completely. This is not a very good situation, and something I will fix. Without this fix, you can just de-select "Raw" and "Pronto Hex", and it should work as you expect, including preserving the commands. Please let me know if this is the case or not.
I tried deselecting "PRONTO HEX" and "RAW" (which wasn't previously selected) on doing a Girr export. The result is here:
https://www.hifi-remote.com/forums/dload ... e_id=13559

On import, I get "IrpMasterException: Command A1: MasterType is parameters, but no protocol found".
Barf wrote:
ncoig wrote:Alas, exporting my information to any format yields a file that, while I can read it and see the data's there, IRS barfs (couldn't resist) on the import and fails entirely.
Please upload one such to the diagnostic area, and describe in detail what you did. If a program generates something it cannot read, that is bad.
See above, I have other export formats as well, but the error is the same.

-N

Posted: Wed Sep 16, 2015 12:23 am
by ncoig
Barf wrote:Try this testversion to see if it solves the problem. If "Raw" or "Pronto Hex" is selected, and the signal cannot be rendered, it still does all the other stuff, including the parameters.

(Overwrite existing IrScrutinizer.jar (or IrScrutinizer-jar-with-dependencies.jar) with this file.)
Is this to test the exporting or importing, or both? (I only ask because I have to rebuild the file each time I run the test because I have to exit IRS to start the importation process, so I want to know which aspect I'm looking at before testing)

Thank you,

-N

Posted: Wed Sep 16, 2015 12:25 am
by ncoig
Barf wrote:
ncoig wrote:... there isn't an "IMPORT ANYMOTE" function.
While I am pretty happy about the procedure for adding export formats (just add to the text file exportformats.xml), the same is not true for the import formats.

However, it would be a rather simple exercise to write a little stand-alone proggie for translating Anymote files to girr, using for example a language like Python (or Visual Basic, or ...). Would that be helpful?
While very kind, that's completely unnecessary - if I can find a way to import from any of the formats you already support, it would be effortless to export it to Anymote on a successful opening of a file in IRS. having it stored natively in that format would seem to me a waste of your talent. :)

-N

Posted: Wed Sep 16, 2015 1:37 am
by Barf
ncoig wrote:I tried deselecting "PRONTO HEX" and "RAW" (which wasn't previously selected) on doing a Girr export. The result is here:
https://www.hifi-remote.com/forums/dload ... e_id=13559

On import, I get "IrpMasterException: Command A1: MasterType is parameters, but no protocol found".
You must select "Parameters" for the export. But that shows another problem: it should not be possible to perform an export with all the formats deselected.
ncoig wrote:See above, I have other export formats as well, but the error is the same.
If this is not covered by the previous problem, please tell me exactly what you do and upload an example file. I am not very good at guessing...
ncoig wrote:Is this to test the exporting or importing, or both?
It contains a fixed export function, that can export the parametric form also if raw or pronto hex fails.