Here's my current plan for coping with the various weird and wonderful things that decoders do when you write to CV1. Comments would be very welcome. Would this really solve the problems that people have seen?
I'm going to provide a new variable type "shortaddr" like the existing "shortAddressVal" like the existing "longAddressVal". It will have one new attribute:
"reset29" with values "no", "std" or a bit-mask e.g. "XXXXXVXX". If "no"
nothing happens when CV1 is written. If "std" or reset29 is not
defined, writing this variable will reset the programs value
for the short/long address bit. If a mask, the bits marked "V"
will be cleared when this variable is written.
It will also be possible to provide sub-elements defining a list of CVs that should be cleared when this variable is written.
So when this variable writes CV1, DecoderPro will change the "known" value of CV29 and perhaps others. That will make those variables as "editted", so if you're doing a write all or write sheet, they'll get written with this new value, etc. As far as I can tell, this will also work when you write through the CV pane (is that working these days) because a write to CV1 from the CV pane will make the short address variable as written, causing it to make the above changes.
There are two possible problems:
a) It's still confusing magic as far as the user is concerned. Even though this is doing something that's "NMRA-correct", it's still pretty fiendish.
b) Some PB has to go through all the files and edit-in the new variable type. I could avoid this by having the code treat CV1 as a very special case, but that would involve changes in a lot of places, so I'd rather fix this right.
Does this sound like an OK solution?
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
Bob Jacobsen