IR.exe KeyMove/Macro layout issue with extenders

[mtakahar]

This issue doesn't affect unextended remotes and perhaps some very old extenders, either.

If you create a regular macro and some special protocols key moves on the same button, the special protocol key moves will be just ignored because IR.exe put all the special protocols key moves after macros. I hope Mark, Paul or someone else can get a chance to fix this problem some time soon.

A workaround is to disable the special protocols tab by commenting out the entire SpecialProtocols section in the RDF then drag any of the key moves or macros before an upload.

Code: Select all

;[SpecialProtocols]
;LDKP=01F9
;ToadTog=0181
;Pause=01FB
;DSM=01FC

Another workaround is not to create the regular macro and create the same Device Specific Macros in all the device modes except for the ones you have the special protocols key moves. Obviously, tihs approach wastes some EEPROM space.


An unextended remote first scans the key move/macro area and looks for only the key move, then it does it again to look for the macro if it didn't find the key move.

On the other hand, most of the extenders only perform a single scan and executes whichever the one found first. These extenders rely on IR.exe's behavior of placing all the key moves before any macros in the key move/macro area to get the same effect as unextended remotes while we can save a dozen or so bytes in the EEPROM by not having the extra code for two scans.


Hal

[e34m5]

Not sure what the question is. But this issue has been discussed before.

Are you trying to have a macro and special protocol on the same key? If so how would the remote discern which one it should execute.

[gfb107]

The point, I think, is that using IR it was possible to have a keymove override a macro for certain devices, because IR would put all the keymoves in front of all the macros.

The new IR seems to store keymoves, then macros, then special protocol functions.

I think Hal is just asking that the macros always be stored last, after the keymoves and after the special protocol functions.

[mtakahar]

Yes, I meant exactly what Greg said.

Are you trying to have a macro and special protocol on the same key? If so how would the remote discern which one it should execute.

You should get the function assigned to the key move if there's one in the current device mode, otherwise the one assigned to the macro. This is a valid programming technique.

Hal

[johnsfine]

You should get the function assigned to the key move if there's one in the current device mode, otherwise the one assigned to the macro. This is a valid programming technique.

That sounds like a suggestion that the extender code be changed, but on reading the whole thread I understand that's not what you mean.

Any space used by code for the extender is space taken away from the capacity for KeyMoves, etc.

So anything that can be done in code on the PC side (IR.exe) rather than in extender code, ought to be done on the PC side.

If I understand correctly (based on what you said about how it works now and on my testing of how it worked long ago, not based on testing it myself now) there used to be a manual work around in IR for a feature that the extenders assumed would be covered by IR (puting KeyMoves before macros). With the addition of IR support for special protocols, even that work around was lost.

Correcting IR would be easier and better than increasing the size of the extenders.

[mpauker]

I just want to make sure that we're all on the same page here...

As far as I can remember, IR doesn't change the order of entries in the AdvCode section. It maintains them in the order in which it read them, and adds new entries to the end of the list. The only time it changes the order is when the user drags a row from one location to another. When this occurs, IR rewrites the AdvCode section and the items wind up segmented by sub-section.

The problem here is that KeyMoves and Macros (and Special Protocol Functions) are intermixed in the AdvCode section, but we display/insert/update them in segmented lists. Because of this, it would be a lot of work to allow a user to specify the exact order of the entries in the AdvCode section (intermixing entries from the various sub-sections).

That having been said, it would be reasonably trivial to change the order in which the sub-sections are written when an entry is moved. At the moment, IR writes KeyMoves followed by Macros, SpecialProtocolFunctions, and FavLists. Would it solve the problem to simply write the SP functions first? Would that break anything else? Is there some other way that IR is reordering the entries that I'm overlooking?

-- Mark

[johnsfine]

it would be reasonably trivial to change the order in which the sub-sections are written when an entry is moved.

That's enough to restore the work around we used to have.

Would it solve the problem to simply write the SP functions first?

The main thing we're asking for is to put macros last. I can't think of a reason why we would care where the SP are relative to other KeyMoves, since it makes no sense to have a KeyMove and SP with conflicting bindings.

When you have a Macro and something else have conflicting bindings, you want the something else to be first. (Conflicting meaning that the macro indicates a specific key in all modes and the other indicates the same key in one mode).

If I remember correctly, at least some extenders process the Fav list like a macro, which should mean KeyMoves and SP must be before the Fav list and we wouldn't care about Fav list vs. macros. But the unextended remote restricts the device mode for Fav list. If any extender preserved that behavior (I don't know) then it would want macros after fav lists.

The safest section sequence I can think of is:
KeyMoves
SP
Fav list
Macros

[Nils_Ekberg]

Before SP's came into the picture they were just keymoves and were processed as keymoves and we did not allow multiple keymoves to be bound to the same device/button. I checked and that is still the case. So that makes it logical that keymoves and SP's be mixed and be first.


I also agree with John that macros should be last so they don't conflict with or override FAV's. Do we actually want to go so far as to restrict the use of the FAV/Scan button if it is set to a device in the FAV/Scan list? We could just do that in the RDF.

Actually as I think about this what is different now if the keymove and SP's are restricted and we have not handled the macros any differently. This problem must always have existed.

[mtakahar]

Fav has always been after macros even before the SP tab came around, though, I agree, the order John suggests makes sense the most.

This problem must always have existed.

I can't find those posts now, but I remember someone was saying an LKP didn't override the macro even after dragging a KeyMove up/down. There were also some other people just getting dismissed by a "Don't assign both on the same button." answer. I didn't even imagine the layout change by IR.exe back then.

Hal

[e34m5]

I haven't been in the code in a while but as I recall we did not change the way SP's or KM's are stored. What is new is simply the way they are displayed.

I'll have to defer to Mark on whether he changed the storage mechanisms in the work he did for IR6.0, although I can't imagine why since that did not need changing.

[mpauker]

Again, the issue isn't a matter of how IR natively stores AdvCode entries... It's how it handles things when rows are moved within a grid. Prior to v6, SP entries were displayed in the KeyMoves grid, so they were sorted together (before the macros) when an item was moved. Now that they're in seperate grids, they're sorted separately. (Each grid is written out individually to maintain the order of the entries within it.) So although the basic algorithm didn't change, the fact that key moves and special protocols are in different grids did cause an alteration.

I will change IR to write the sections in the following order: KeyMoves, SpecialProtocols, Favs, Macros. That having been said, I still think that it's worth mentioning that deleting the macro and recreating it would cause it to be moved to the end of the list. (Of course it would get resorted the next time a row was moved.)

[mtakahar]

Mark, thanks for taking care of this so quick. The 6.15 is working perfectly.

Again, the issue isn't a matter of how IR natively stores AdvCode entries... It's how it handles things when rows are moved within a grid
...
That having been said, I still think that it's worth mentioning that deleting the macro and recreating it would cause it to be moved to the end of the list. (Of course it would get resorted the next time a row was moved.)

Perhaps this (a need of moving a macro/KeyMove to trigger reordering) deserves a place in the top 5 extender programming tips.

I've been mentioning this in the documentations for my extenders and LDKP.


Hal

P.S. I've updated the link to IR in the Files Section in THIS Forum, which I created recently since someone was having trouble finding it.