I keep running into this sort of problem. It tells me that I am misunderstanding something fundamental. It could be that the system has a bug, but if so it is unlikely to get fixed so I need to learn how to live with the current situation, buggy or not.
I have two properties that I do not want to both be true at the same time. They are not radio properties, because it is fine (and in fact normal) for them to both be false at the same time. It is just wrong to both be true at the same time.
Here is the code that I expect to implement that:
The code works as designed -- except that some outside unwanted actor is also calling in and upsetting the apple cart. Starting from the situation where:
I set ShowBarNumbers true. That is intended to have the effect of both setting it true, and forcing ShowBarNumberAtCursor false. I put Print() statements in the set methods for tracing. The number in parentheses is a unique monotonically increasing object ID. It shows that a new object got created -- not necessarily a problem, although it is one in this case. Here is the trace, with my annotations:
I do not know whether all of that object creation and property calling is due to NT or is inherent in .NET. As Mr. K has previously observed, I am clearly surprised by it. My code expects that if it sets a property that property will remain set, not have some other actor come along with a different idea of what the property value should be. I have previously clearly expressed my view that this is a system bug -- that when I write code I expect any behind-the-scenes stuff, such as unrequested object creation, to be transparent. The above is clearly NOT transparent.
Last time I brought this issue up, I was asked for code. That case was more complicated, so supplying code was not practical. This case is very simple, though, so I hope the code I have supplied meets that request.
Now let's get realistic -- it does not matter whether or not the system has a bug, this behavior is unlikely to get changed, at least in V7. Changing it would be a lot of work, introduce a lot of risk, and almost certainly break existing user code. I would not change it if I were an NT developer. Not going to happen, at least in V7.
So, the real question is how should I write the code to live nicely with V7? Surely it is a reasonable request to be able to set up two properties so that at most one of them is true at any given time.
One obvious idea is to move the code that enforces the condition elsewhere, such as to OnStartUp(). The problem with that is OnStartUp() has no way to know which of the two should be left true, and which should be forced false.
--EV
I have two properties that I do not want to both be true at the same time. They are not radio properties, because it is fine (and in fact normal) for them to both be false at the same time. It is just wrong to both be true at the same time.
Here is the code that I expect to implement that:
Code:
bool showBarNumbers = false;
[Description("Show the number of each bar. (Useful for selecting a precise interval or for debugging.)")]
[GridCategory("\tBar Numbering Parameters")]
[Gui.Design.DisplayName ("\t\t\t\t\tShow bar numbers")]
public bool ShowBarNumbers
{
get { return showBarNumbers; }
set {
Print("DEBUG: (" + idString() + ") showBarNumbers=" + showBarNumbers + " value=" + value);
showBarNumbers = value; if (value) ShowBarNumberAtCursor = false;}
}
bool showBarNumberAtCursor = false;
[Description("Show the number of the bar the cursor is on")]
[GridCategory("\tBar Numbering Parameters")]
[Gui.Design.DisplayName ("\t\t\t\tShow bar number at cursor")]
public bool ShowBarNumberAtCursor
{
get { return showBarNumberAtCursor; }
set {
Print("DEBUG: (" + idString() + ") showBarNumberAtCursor=" + showBarNumberAtCursor + " value=" + value);
showBarNumberAtCursor = value; if (value) ShowBarNumbers = false;}
}
- ShowBarNumbers = false
- ShowBarNumberAtCursor = true
I set ShowBarNumbers true. That is intended to have the effect of both setting it true, and forcing ShowBarNumberAtCursor false. I put Print() statements in the set methods for tracing. The number in parentheses is a unique monotonically increasing object ID. It shows that a new object got created -- not necessarily a problem, although it is one in this case. Here is the trace, with my annotations:
Code:
DEBUG: (#54) showBarNumbers=False value=False DEBUG: (#54) showBarNumberAtCursor=False value=True DEBUG: (#54) showBarNumbers=False value=False DEBUG: (#54) showBarNumbers=False value=False DEBUG: (#54) showBarNumberAtCursor=True value=True DEBUG: (#54) showBarNumbers=False value=False [COLOR=Blue]Above here is the final state after the previous action. Note that ShowBarNumbers = false, and ShowBarNumberAtCursor=true The following output all happened as a result of changing ShowBarNumbers to true in the GUI IMPORTANT NOTE: the old object was replaced with a newly constructed object [/COLOR]DEBUG: (#62) showBarNumbers=False value=True [COLOR=Blue]ShowBarNumbers got called and changed its value from false to true, as requested[/COLOR] DEBUG: (#62) showBarNumberAtCursor=False value=False [COLOR=Blue]ShowBarNumbers called ShowBarNumberAtCursor to set it false. Note that it was already false -- the default state of the newly constructed object The system plans to initialize the new object by calling property set methods Unfortunately, that is a big problem because it undoes the side effect of calling ShowBarNumbers [/COLOR]DEBUG: (#62) showBarNumberAtCursor=False value=True [COLOR=Blue]OK -- here it is -- the system now sets ShowBarNumberAtCursor to true That is the last value [I]it[/I] knew about, but setting that is a problem because it undoes what ShowBarNumbers just did. [/COLOR]DEBUG: (#62) showBarNumbers=True value=False [COLOR=Blue]This is ShowBarNumberAtCursor reacting to the erroneous setting it true by forcing ShowBarNumbers false === Below here is yet another object being created as the result of that one user GUI action [/COLOR]DEBUG: (#70) showBarNumbers=False value=False [COLOR=Blue]System setting ShowBarNumber false, which is what it ended up after the #62 fiasco[/COLOR] DEBUG: (#70) showBarNumberAtCursor=False value=True [COLOR=Blue]System setting ShowBarNumberAtCursor true, which is [/COLOR][COLOR=Blue]what it ended up after the #62 fiasco[/COLOR] DEBUG: (#70) showBarNumbers=False value=False [COLOR=Blue]This is ShowBarNumberAtCursor setting ShowBarNumbers false [/COLOR]DEBUG: (#70) showBarNumbers=False value=False [COLOR=Blue]I do not know who is makeing this call, or why[/COLOR] DEBUG: (#70) showBarNumberAtCursor=True value=True [COLOR=Blue]I do not know who is makeing this call, or why[/COLOR] DEBUG: (#70) showBarNumbers=False value=False [COLOR=Blue]This is ShowBarNumberAtCursor setting ShowBarNumbers false [/COLOR]
Last time I brought this issue up, I was asked for code. That case was more complicated, so supplying code was not practical. This case is very simple, though, so I hope the code I have supplied meets that request.
Now let's get realistic -- it does not matter whether or not the system has a bug, this behavior is unlikely to get changed, at least in V7. Changing it would be a lot of work, introduce a lot of risk, and almost certainly break existing user code. I would not change it if I were an NT developer. Not going to happen, at least in V7.
So, the real question is how should I write the code to live nicely with V7? Surely it is a reasonable request to be able to set up two properties so that at most one of them is true at any given time.
One obvious idea is to move the code that enforces the condition elsewhere, such as to OnStartUp(). The problem with that is OnStartUp() has no way to know which of the two should be left true, and which should be forced false.
--EV
We can arrange for you to see my screen as I set these properties, and we can see that they are sticky. I do not have your object creation code in my setup, so I have removed the idString() call from your debug lines.
Comment