In the short term , continuing to explicitly add tests on parameter ID in IsParameterCommandModeSettable() is the way to go. I’ve also discerned from reading the code that it is expected that whoever is trying to set a parameter is responsible for calling IsParameterCommandModeSettable() and only changing the value if it returns true. I didn’t see anything internal to the SetParameter() functions that was doing this.
I have created the start of a process for determining which parameters are changeable in command mode and a template for recording decisions about each parameter. Those files were e-mailed to Darrel a while back.
For the long term solution, there are two options, one of which is conceptually easy but entails a lot of work that must be done all at once, the second of which is a lot of work, but allows it to be done over time. In addition, it may be able to add protection against bad parameter changes, reading the GmatBase derived code alone makes it look like even if you test to see whether something is changeable there is nothing to actually prevent the change from being made. To be fair, I haven’t read the Interpreter code that would make that decision.
Option 1 – in GMAT base, simply set the default to allow command mode parameter setting (by returning true), and continue to expect caller to check before setting parameter when in command mode. The drawback is that we need to check every parameter in the system to determine if we want to disallow command mode updates of the value. We would also need to document these decisions in the User Interface Spec document, and update that document to be consistent with the code.
Option 2 – keep the default as is, and go through all the code to add permission to change where appropriate. This is probably more effort than Option 1, but it doesn’t have to be done all at once. We would still need to update User Interface specification to be consistent with code.
Protecting from bad changes – have objects determine for themselves if they are in command mode to add protection against bad calls to set parameters. I am assuming that the system’s run state is kept somewhere and that GmatBase could access that “somewhere” to determine whether the system was past BeginMissionSequence. This may not be necessary, if check is already done in the Interpreter and the assumption that the check is always done is documented in the Interpreter design.
That is the result of my investigation, which has all been done by examining EphemerisPropagator. I implemented most if not all the changes for that class. The ticket also calls out the DifferentialCorrector and OrbitView; If these are needed for our customer Voldemort my suggestion is to go ahead and do them leaving “return false” in GmatBase. IsParameterCommandModeSettable(), because there is no way we’ll get the wholesale changes made in a short time span.
I will call this investigation ticket resolved, and we should put in 1 or more tickets for the implementation of these changes in EphemerisPropagator, DifferentialCorrector, and OrbitView, depending on whether you want me do all of them or to split the work.