JP1 Remotes

I hunted through the threads concerning new IR development. I like the improvements in IR v5.01, though I've had trouble figuring out saving. Over all, the new features seem like real wins.

A nice solution to the incompatibility problems, and an improvement (I think) in the overall UI of the JP1 toolchain would be to integrate extInstall's functionality into IR. IR seems like the right place to do this, and this seems like the right moment in the evolution of the tools to make the suggestion.

Thoughts?

Ken

I agree.

e34m5 wrote:I agree.

Do we have the same interpretation of what you're agreeing to?

Fixing ExtInstall for the new ir file format is high on my list of overdue work, but if it were integrated into IR, it wouldn't be needed as a seperate program.

I'll still go ahead and fix ExtInstall because I'm sure integrating it into IR is too hard to be a short term (as in the "right moment" phrase above) goal for IR.

The ExtInstall process heavily depends on viewing the contents of an eeprom image as logical objects rather than directly as an eeprom image. The recent IR changes are a step in that direction, but I don't think far enough for ExtInstall integration. Probably more steps in that direction are a good short term goal for IR.

I think that fairly soon the IR file format should go to an almost entirely redundant representation of eeprom contents.

Initially, the whole eeprom contents were represented by the eeprom image. Now we have some KeyMove info (and I'm not sure what else) redundantly contained in another form (which of course also has non redundant info in it).

I'd like to see all the variable count elements of eeprom contents fully represented in the new file sections: KeyMoves, Macros, Device Upgrades, Protocol Upgrades, Learned Signals, and Fav lists.

You can then switch to a design that says those sections of the eeprom image are totally rebuilt from the other form whenever it is convenient to do so. That in turn eliminates all the complexity of switching to a different RDF that specifies a different way of storing some or all of those object types.

Perhaps what we could do in the interim is make a call to ExInstalll from IR. That way the user doesn't have to "run" another app. Since you are already making the changes for the new format adding tha call from within IR should not ne difficult. I can make so that as soon as ExInstall completes it's thing, the new file is automatically opened in IR.

Later, as you mentioned we can think of integrating more and more stuff into IR.

I was actually going to suggest the same thing as an interim solution. In addition to the call for ExtInstall you would just need to add the appropriate file open/selection command for the input(s).

IR would also have to make sure the required files for ExtInstall are present and pass a message if they aren't.

Exactly

And, if it doesn't do that already, code ExtInstall to:
1. Run silently with an appropriate switch (no prompts).
2. Return status code to the calling program

Ok...I have exinstall running from IR. All I need to do now is create a list of all the extenders and their corresponding file names.

I have uploaded a new beta v5.03 with ExtInstall support. Look under file|Convert for extender. Let me know what you think.

IIRBETA503

e34m5 wrote:I have uploaded a new beta v5.03

You really need to give the beta .exe a unique name so that people don't go and overwrite their good copy (like I just did because I was't paying attention ).

Let me know what you think.

Am I correct in assuming that ExtInstall needs to be in the SAME directory as IR? Do you think maybe you can add a "Set ExtInstall Path..." option like the one for RDF's?

Hey Mark

With all the testing if IR I got in a habit of renaming the current working IR as "IR Current.exe". Actually that is the same concept I use with upgrade files also. ie: Current and Test in the name

Paul will probably give you the same answer but it is late and I am sitting in a hotel bored. Extinstall needs to be in the same folder as the RDF's everything else can be anywhere. Currently Extinstall is OK with fully qualified paths for everything but the RDF and expects them to be visible in the same folder.

I sent Paul and e-mail on another problem where after all files are selected I get a message that the new file can not be opened. I also can't open it from the file/open either until I shut down IR and reopen it. Other than that it creates a good extender file.

Oops..I forgot to rename it like I have in the past..I guess I was in a hurry.

The ExtInstall.exe and the RDF's need to be in the same directory (both the non-extended and extended RDF). Evrything else can be fully qualified including the location of the .HEX definition file. Therefore the Set RDF path is the key to that piece.

As far as Nil's situatuion I don't know. I created about a dozen with out any problems. One thing is funny however, if you try to convert a converted file (which I tried by accident) ExtInstall get's really angry.

I am planning on documenting this on the release notes.

Paul, no matter where I put the input.txt file and the output.txt file I get the message "Cannot open c:\jp1\Test.txt.". Note that there is an extra DOT after the file name. If I select an existing file as output it prompts me to write over it and does the conversion and then opens the new file fine.

Also, after it gives me the can't open message I can't open any file except the .hex file since that is the only file type it offers me unless I close and reopen IR.

IRBETA503.zip

Check this one..I made some adjustments....had to add some funky code for the files to open automatically.

By golly Paul I believe you got it this time. Worked as expected and I tried it from all kinds of different folders. The only thing I left consistent was the requirement of Extinstall being in the RDF folder.