IR editing questions

Post by **ElizabethD** » Wed Jul 28, 2004 3:03 pm

IR 509
1. Is there an way to copy a macro for editing trial versions?
2. Is there a way to comment out alternative macros during construction? If not, any suggestions for quick trials of versions (standard use or extender, it shouldn’t matter really) will be much appreciated.
3. I noticed that sometimes IR saves 3 files. <Filename>.IR has the same time as a file “txt” with no extension, and <Filename>.txt is previous. No big deal, just wondering which of the txt files to use if don’t want to use the *.IR version. Am I messing something up? I suspect the one with the time in synch with the *.IR file, and the other one is a backup. Right? Wrong? Maybe?

e34m5 · Post by **e34m5** » Wed Jul 28, 2004 5:06 pm

Not sure I understand your questions 1 and 2.. you can clone a macro and assign it to another device and key combination.

What are you trying to do...

Post by **The Robman** » Wed Jul 28, 2004 5:30 pm

I don't understand the questions either (1 & 2, that is)

johnsfine · Post by **johnsfine** » Thu Jul 29, 2004 9:10 am

I think I understand and it's been on my wish list for a while (though not HIGH on the wish list).

It's a request that makes sense as more of the config is redundantly described by the extra data as well as by the raw hex.

Elizabeth wants whats described below for Macros. I want it for almost all configuration elements.

The ability to include things in the non_raw_hex portion that are not included in the raw hex portion.

If the state of being included in the raw hex portion is easy to turn on and off, it becomes a powerful feature for maintaining and testing your config.

You can get the same net effect by keeping the objects elsewhere and using various cut/copy/paste actions to install and deinstall them. But it would be more convenient to be able to keep elements in the .IR file but flagged as disabled.

e34m5 · Post by **e34m5** » Thu Jul 29, 2004 10:45 am

I have no idea what you said...

johnsfine · Post by **johnsfine** » Thu Jul 29, 2004 11:02 am

e34m5 wrote:I have no idea what you said...

I'll try again.

You know what I mean by config "elements" (Macros, Keymoves, upgrades, etc.) right?

You know what I mean by elements being stored "redundantly" between the raw hex and other portions of the .ir file, right?

Most of my wish list depends on making that more redundant, so the non raw hex portions form a nearly complete specification of the config and the raw hex portions are almost all redundant. You know what I mean by wanting IR to move in that direction, right?

Now pretend (I assume it isn't true yet) that the non raw hex part of the .IR file totally specifies the macros, so the raw hex version of the macros is redundant. You would know how to do that if you wanted to, right?

Finally, add a "disable" flag to the non raw hex version of a macro, and add some GUI to support turning that flag on and off. When the "disable" flag is set for a given macro, that macro is removed from the raw hex area and remains only in the other area. Understand?

Then a user could "temporarily remove" a macro by setting its disable flag, so it wouldn't go to the remote when the raw hex is uploaded, but it would remain in the .ir file (for various reasons including the ability to get it back enabled easily).

e34m5 · Post by **e34m5** » Thu Jul 29, 2004 11:08 am

Ahh...the final sentence finally made sense

So perhaps the way to do that is have a checkbox on the dialogs that would allow you to disable the macro.

This sounds doable....let me noodle on it for a while.

Nils_Ekberg · Post by **Nils_Ekberg** » Thu Jul 29, 2004 11:10 am

e34m5 wrote:I have no idea what you said...

I think I understand.

Basically, allow multiple versions of a macro or keymove or protocol or a whatever and have a selection button next to it that says include this in the raw data or not.

This way you could for example, add two versions of a keymove but one must/would be inactive and stored someplace other than the raw data (notes area for example). A second example would be to be able comment out (turn check box off) an item to rule it out as a problem.

I envision something like this to be that every thing added to IR would be by default checked ON but you could check it OFF for testing. Only those items checked ON would be in the raw data.

e34m5 · Post by **e34m5** » Thu Jul 29, 2004 11:14 am

Perhaps the saved config file could have two sections. One would be the hex that is loaded to the remote and the other would contain that plus the info not to be loaded.

In many cases the sections would be identical..bit since text files are so small this is not a big deal.

This would continue our trend of storing all the info fo a configuration in one file.

Post by **The Robman** » Thu Jul 29, 2004 11:18 am

Paul, I think I know what they're getting at. IIUC, the suggestion is that there be a temporary "disable" checkbox next to each keymove and macro, then when the checkbox is set, IR would move the hex code for the keymove or macro to a new portion of the .IR file, which would be created just for this purpose. The data stored in this section would not be loaded into the remote and would therefore not be part of the conventional .txt EEPROM image.

When the .IR file is re-opened at a later stage, the macros and keymoves stored in the new section should be included in the existing macro and keymove lists, but with the "disable" checkbox set.

Another possibility is that do indeed store the data in the remote but store it after the final "00" byte. If you go this route, I would suggest that you use a marker of some sort in the first byte after the "00" byte, just to give you a higher level of confidence that the data that follows is indeed the data the you put there, as opposed to regular garbage data.

e34m5 · Post by **e34m5** » Thu Jul 29, 2004 11:23 am

I would be more comfortable having two sections in the .IR file. That should be fairly simply to implement. The change would involve inserting the check for disable in the code that writes the data and determine where to write this in the file.

I'd like to put this only in the IR file to save time and coding..what do you guys think....

Capn Trips · Post by **Capn Trips** » Thu Jul 29, 2004 11:36 am

The Robman wrote: ... the suggestion is that there be a temporary "disable" checkbox next to each keymove and macro, ...

I'm way out of league in this discussion, but suggest that if you're going to the trouble of modifying IR.exe to allow selective enabling/disabling of Keymoves and Macros, could the same be done for entire Device and Protocol upgrades?

e34m5 · Post by **e34m5** » Thu Jul 29, 2004 11:38 am

Capn Trips wrote:
The Robman wrote: ... the suggestion is that there be a temporary "disable" checkbox next to each keymove and macro, ...
I'm way out of league in this discussion, but suggest that if you're going to the trouble of modifying IR.exe to allow selective enabling/disabling of Keymoves and Macros, could the same be done for entire Device and Protocol upgrades?

Should be able to do that...

johnsfine · Post by **johnsfine** » Thu Jul 29, 2004 11:44 am

I'll try again, again. This time after actually looking at a .IR file, so I can be more specific. Because I'm not sure whether you're all disagreeing with me or not understanding me. If you're disagreeing, there are aditional reasons for the way I prefer that I'd try to argue, but first maybe you're not understanding what I'm proposing yet.

A macro is now not stored very redundantly. The body of the macro is in the [buffer] section somewhere and the notes for the macro are in the [Macros] section.

I propose changing the structure of the [Macros] section (or if you REALLY prefer adding a helper section associated with it) so that it contains the bodies of the macros as well as the notes, plus a place for a disable flag.

Then the macro definitions within the [buffer] section would be redundant. When appropriate, IR would replace all the macro information in the [buffer] section with a reconstruction based on information from the [macros] section.

I certainly don't want to see two [buffer] sections (for things that are in vs. things that are out) and I don't want to see a way of shoe horning the disabled stuff into the buffer section (such as the dead space after the 00).

I have other ideas for the dead space and I want to allow the [macros] section to hold more than would fit in the [buffer] section.

Remember, another wish list item that would be based on the same .IR file changes is that an extender install program (or maybe the user directly) could add a macro that doesn't fit. That macro would be in the [macros] section and wouldn't be in the [buffer] section. Note it is not disabled in the [macros] section. IR would recognise and report an error condition (there are enabled macros in the [macros] section that don't fit in the buffer section) but it
wouldn't be forced to discard the excess macro from the file. The user could save the .ir file and fix it later. Later the user could delete some unrelated macro or KeyMove and as soon as the room was available the things that were there not fitting would automatically get in.

e34m5 · Post by **e34m5** » Thu Jul 29, 2004 11:57 am

It is much easier from a code perspective to maintiain to sections in the file [buffer] and something else like [IR]. That is because the code that read and writes raw data would not have to change.

If we add hex data to the other sections then we would need to add a bunch more code to meld the raw data with non raw data.