JP1 Remotes

mtakahar · Expert Joined: 03 Aug 2003 Posts: 281

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.

e34m5 · Joined: 14 Oct 2003 Posts: 675 Location: Atlanta

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.
_________________
Paul

gfb107 · Expert Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC

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.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

mtakahar · Expert Joined: 03 Aug 2003 Posts: 281

Yes, I meant exactly what Greg said.

johnsfine · Posted: Tue Jun 21, 2005 6:45 am Post subject:

mpauker · Expert Joined: 03 Aug 2003 Posts: 40

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 · Posted: Wed Jun 22, 2005 6:41 am Post subject:

Nils_Ekberg · Posted: Wed Jun 22, 2005 8:28 am Post subject:

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.
_________________
Nils
Files Section
Diagnosis File Section

mtakahar · Expert Joined: 03 Aug 2003 Posts: 281

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

e34m5 · Joined: 14 Oct 2003 Posts: 675 Location: Atlanta

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.
_________________
Paul

mpauker · Expert Joined: 03 Aug 2003 Posts: 40

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 · Expert Joined: 03 Aug 2003 Posts: 281

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