It had escaped my notice that the Checkbox control had transitioned from a bi- to a tri-state control.
Can someone give an example where you would use an indeterminate checkbox state in a user interface?
It had escaped my notice that the Checkbox control had transitioned from a bi- to a tri-state control.
Can someone give an example where you would use an indeterminate checkbox state in a user interface?
Anytime the UI should indicate either that the value is unknown (similar to null instead of zero for a value), or there is a mixed state.
For example, think of a tree view of folders and nested contents, with a checkbox to indicate selection (say for backup or whatever).
A checkbox on a folder level might indicate:
Thanks Douglas.
One thing that concerns me is how the Value and VisualState properties can interact. A checkbox can be set to act in a bi-state mode (toggling between checked or unchecked) or in a tri-state mode (switching between checked, unchecked, and intedeterminate) modes.
When one sets a checkbox visualState property to “checked” or to indeterminate , the value property is automatically set to true. Therefore you cannot distinguish, in code, whether a checkbox is checked or indeterminate without using the visualState property. It seems then that the Value property is no longer needed (and should be deprecated).
@Craig Hyde “Value” may still be useful when using a 2-state CheckBox. “State” should be used for 3-state CheckBox
Agreed… I use Checkboxes nearly 100% of the time as 2-state and use the Value property only. When I want to test wether a checkbox is checked, muscle-memory in my fingers types out: " If Checkbox1.value = true Then … "
The problem I see is that there seems to be no way to tell from code whether a checkbox is in the “2-state” mode or the “3-state” mode. If you find that a checkbox’s value is “True”, then to be safe, you would also have to test the VisualStates property as well to make sure that the VisualState is “checked” and not “indeterminate”. In other words, the “value” property is of limited value, so to speak.
Isn’t indeterminate
only available in code and the IDE? There’s no user action or input that I’m aware of that can cause it. So if you set the control value in the IDE to either checked
or unchecked
then it should behave solely as a binary value.
@Tanner Lee Yes you can make a CheckBox allow indeterminate state from a user’s click, so it is not only a pure code/IDE thing.
For example, you may want to ask the user if they want something to be:
added (checked)
removed (unchecked)
left untouched (indeterminate)
I think the following may be a more accurate and complete summary:
IF the IDE sets the visualState to checked or unchecked , the checkbox is set to the two-state mode and the user can only toggle from checked to unchecked (until and unless code changes the mode to three-state).
IF the IDE sets the visualState to indeterminate, the checkbox is set to a three-state mode where the user can cycle from checked to unchecked to indeterminate (until and unless code changes the mode to two-state).
IF code changes the Value to true or false OR code changes the VisualState to true or false, then the the checkbox is set to a two-state mode and the user can only toggle from checked to unchecked.
If code changes the VisualState to indeterminate, then the checkbox is set to a three-state mode where the user can cycle from checked to unchecked to indeterminate.
Code can determine if a checkbox is unchecked using either .value = false or .visualState = visualStates.unchecked. But my point is that code can only determine whether a checkbox is checked using .visualState = visualStates.checked. If .value = true , then the checkbox could either be checked or intermediate, thus begging the question “what is the value of the .value property?”
As I see it, there are three solutions:
ask XOJO to deprecate the .value property with extreme prejudice and force us to use the VisualStates enumerations.
ask XOJO to create a new property (ex. .mode) so that code can determine whether a checkbox is operating in binary or trinary mode.
[quote=470211:@StphaneMons]@TannerLee Yes you can make a CheckBox allow indeterminate state from a user’s click, so it is not only a pure code/IDE thing.
For example, you may want to ask the user if they want something to be:
added (checked)
removed (unchecked)
left untouched (indeterminate)[/quote]
My point exactly. Only the programmer can set it - either with code or by setting the control’s state value in the IDE.
There is no way for a user to set the indeterminate
state in a running application i.e. with a mouse click or keyboard input.
So if the control in the IDE is set to either checked or unchecked, it becomes a de facto binary control.
And your brain may think:
If CheckBox1.Value Then
or better, replace CheckBox1 by a meaningful name using CB as prefix (maybe) ?
Emile, In practice, I do tend to use “more meaningful” names as you suggest, but my point was that I (and most developers) may simply write:
If CB_nicelyNamedCheckbox.value Then…
rather than
If CB_nicelyNamedCheckbox.visualState = checkbox.VisualStates.checked Then …
The latter is more precise and avoids potential errors if there is a possibility that the CB is operating in the tri-state mode.