JP1 Remotes

e34m5 wrote:meld the raw data with non raw data.

I'm not sure what you mean by "meld".

I believe IR.EXE already extracts the macros from the raw data as a collection of objects. When you do something like resequence KeyMoves, I believe IR reconstructs the raw data form of the macros from the collection of objects form. So I think much of what I want already exists.

Clearly it would be more file parsing work to be able to read macro bodies from a Macros section than to be able to read them from a second Buffer section, and it would be a little more work to write them there when saving a .ir file.

But a second buffer section addresses only the disable feature. The other way addresses many features. A second buffer section limits the disabled items to the size of collection which fits. A second buffer section slightly increases the complexity of the management code (things like the transitions as you turn disable on and off) eating up most of what you might save by not writing code to parse macro bodies in the Macros section.

Don't take any offense but I don't want to get into a philosophical discussion on this. I'll explore your suggestions as well, but ultimately I need to be able to implement this in a way I can manage it.

I would hardly characterize any of this discussion as philosophical. I thought John was quite clear in stating what he wants.

You already store notes in the [Macros] section. John wants you to also store the information necessary to construct the hex data in the same section. He also wants you to store the "enabled" checkbox status in this same section.

Currently, when IR loads a file, it builds the list of macros displayed in the GUI based upon reading the hex data in the [Buffer] section. You would change this so that it builds the list from the data stored in the [Macros] section. It would also build the hex data for the [Buffer] section from the same data. The actual hex data in the [Buffer] section of the saved file would not be used for the GUI (i.e., it is redundant). It's still a good idea to keep saving it as-is, since the EEPROM image stored in the file is used by other programs, and for troubleshooting.

Yes, there are complications to this. You'd probably still need to maintain the current logic for loading older IR files that don't have the [Macros] section.

Again....I will attempt to implement this in a way that works based on my knowledge of IR and my coding abilities.

It may not be the way John envisions it...but will hopefully in the end provide the necessary functionality.

To all:

johnsfine wrote: 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.

Precisely . And convenience is key. Thanks, John.

I didn't want to propose a disable flag, because I don't know how IR is built or when the raw data part fills, since moving bytes about isn't trivial, especially when I always end up being 1 byte off in space calculation. And I have no intention, nor any skills, to meddle in how to do it. This answer is based just on a fast peek here.

Million thanks for what looks like great reading for tonight

As proposed by Capn Trips, a common algorithm might apply to protocols and devices, as well. But, at least for me, the rough part are the laborious areas - keymoves, macros. Moving protocols out of KM isn't so tough, but then I haven't done as much as the authors of all the answers.

New item:
If someone really takes this on, I'd like to add another twist: being able to change sequential position of keymoves and macros , unless logic prohibits, in a fashion, for instance, similar to that of building a macro or Excel's insert of copy or cut row.

Once again, this is a developing convenience item, where one could group everything dealing with DVD together, or everything dealing with shutting things down, or whatever other logic, or lack thereof, one selects.

Being able to understand, months later, what one built would be nice, and grouping in user-defined categories might help. When I think of keymoves that might get built with an extender it begins to look like an enormous list. Keeping it orderly would be neat.

I got the easy part this time - making a shopping list

Nils_Ekberg wrote: 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.

Yup. If IR were mine, that's exactly what I'd do from day1. How to do it is a whole other story and not mine!

ElizabethD wrote:being able to change sequential position of keymoves and macros

You can do this now manually by dragging the "#" column up or down within the list.

Mark Pierson wrote:You can do this now manually by dragging the "#" column up or down within the list.

Mark,
That sure was one challenging procedure . Must have missed it in readme.
Any other tricks?

ElizabethD wrote:Must have missed it in readme.
Any other tricks?

I don't think it's in there! Mark Pauker told me about that "feature" a long time ago. I think it's actually part of the Delphi grid control and not necessarily magic on IR's part.

As for other tricks, I'm not aware of any besides this one.

Not sure how I knew about that, but I did, so I implemented something similar in RM on the Function panels.

e34m5 wrote:Again....I will attempt to implement this in a way that works based on my knowledge of IR and my coding abilities.

It may not be the way John envisions it...but will hopefully in the end provide the necessary functionality.

Paul,
Looks like you've been selected to do the work Have fun!

My reading is that it can be done. It's worth it, believe me. We, beginning people, barely can manage what to put in, so anything that makes it easier is worth it even if, compared to decoding, protocols etc it's low priority.

John mentioned that overflows would fall under similar logic. Much of the detail is over my head, still, I did run into that a little while back, but not with macros. I didn't do my arithmetic too well before Extinstall and found myself with an orphan upgrade - no protocol 'cause it didn't fit. If whatever effort you put into the on-off flag generalizes to this, it would be nice.

BTW, very sorry for fuzzy question. I thought, of course, it was crystal clear