Mark Pierson wrote:There's no need to close and re-open RM in this case. Simply select a different remote and then re-select the desired one. RM should re-read the "new" RDF.
Yes, there is. RM only reads the .RDF once, the first time you select a remote. It keeps the definition in memory for future use. If that turns out to be an issue, I can change the design.
Having said that, most of the time users don't edit .RDfs. They just use pre-existing ones.
gfb107 wrote:RM only reads the .RDF once, the first time you select a remote. It keeps the definition in memory for future use. If that turns out to be an issue, I can change the design.
I stand corrected... maybe that's why whenever I use RM my system resources go out the window (I'm always changing remote models, etc)!
Thanks for that, Mark *almost* had me convinced I was seeing things.
Kent may need to play with the rdf for the intuitive to fine tune the rdf. Is there a way, maybe in the top menu selection to turn on/off that first time memory rememberance? Then RDF developers and tweakers can manually turn it off temporarily and turn it back on when finished with a session. You might pop up a warning message to caution most "normal" users against doing this. I know Rob and John probably could use this anyway. Likely John's personal copy already has this. Another may be Mike E, Jason, Dave, etc.
It's almost the same with IR.exe, whenever I change an RDF I have to open a file for a different remote, then re-download the remote I'm testing. I know I'd like an option in IR to always make it re-load an RDF, so I guess it would be a good option for RM also.
The Robman wrote:Just FYI, re: the "0" thing. That stems from the fact that the "0" button is positioned right before the "1" in every keymap in every remote. I don't know if you've ever noticed, but the order of the buttons in KM's Buttons sheet comes from the VCR device mode in the 15-1994, which is of course, the remote that the whole JP1 project was based on, before it expanded to include all the other remotes.
Is there any problem with rearranging the ButtonMaps section so that the "0" button comes after the "1"? Or will this cause a problem with the upgrade code?
cdhixson wrote:Is there any problem with rearranging the ButtonMaps section so that the "0" button comes after the "1"? Or will this cause a problem with the upgrade code?
The sequence in the ButtonMaps does define the sequence in the upgrade when a DigitMap isn't used and is coordinated with the definition of DigitMaps for when digitmaps are used, so you couldn't just change the sequence in the RDF and get desirable results.
It is ultimately just a GUI question, so it could be changed:
There is no absolute need for any aspect of the GUI layout to match any aspect of the upgrade's hex layout, so it doesn't need to cause a problem with the upgrade code. But
To be done consistently, it would need changes to RM and KM and IR. It's a fair amount of work and coordination and disruption (for everyone who is used to the way it works now) all for a change of very questionable benefit.
Just a quick question on the file I uploaded to the
site which is a merge of Nils and Rob's rdfs for the intuitive
remote. Rob moved the Buttons around in the button
section, does that matter if so you may want to
use his bit for that part.
What I mean is
I had them in numerical order while he had them in button
order I think.
me
[Buttons]
vcr=$01,tv=$02,cable=$03
Rob:
[Buttons]
tv=$02,vcr=$01,cable=$03
(not real data just getting the point across)
That sequence controls the sequence of pull down menus in IR from which you can select a key. It doesn't control anything about the content of upgrades or keymoves (so it is purely a GUI issue, unlike the sequence within button maps discussed above).
I'm not sure what (if anything) it affects in RM.
I really prefer a logical sequence to buttons (group device keys together, group transport keys together, etc.). Many people prefer a physical sequence (based on position on the actual remote, which tends to be just a little different from a logical sequence). I think a numeric sequence (by keycode) is much less usable (though that sequence is an important reference source for experts doing advanced things).
If this matters at all in RM, I think the existing option to use a picture of the remote instead of the buttons sheet reduces the need for the buttons sheet to be in physical sequence and increases the value of having it organised by logical type of key.
That sequence controls the sequence of pull down menus in IR from which you can select a key. It doesn't control anything about the content of upgrades or keymoves (so it is purely a GUI issue, unlike the sequence within button maps discussed above).
If the RDF author uses the option to omit the key code numbers, then IR also uses the sequence to assign key codes, in which case you cannot just rearrange them at will. However, if the key code numbers are specified (as is the case in your RDF), then you are free to arrange them more logically for the benefit of the GUI.
Example:
TV, VCR, Cable
This would list them in the GUI in the order shown, but also assign key codes TV=$01, VCR=$02 and Cable=$03 to the buttons.
Button order in the .rdf does matter (slightly) to RM. It impacts the order buttons are displayed on the Button panel. However, first RM scans through the ButtonMaps looking for the longest ButtonMap.
It places the buttons in that longest ButtonMap first (in the same order as in the ButtonMap), and then adds the remaining buttons, in the same order as defined in the .RDF.
