LabVIEW
Why can't I make a boolean case default?
I have a fairly simple case structure. I need to make the True case the default case. I see in the help to make a case default right button click on the case selector and select "Make this the default case". When I right button click I do not have that option:
I have also tried the optional method of adding "Default" without the quotes and it just reverts to what was there before. I have also tried creating a case block with three text cases (rather than a boolean) and I cannot set default that way either.
What am I missing?
Hi flycast,
@flycast wrote:
I need to make the True case the default case.
What am I missing?
You are missing that there is no default case possible with a simple True/False input!
Why do you even think you need to set that case as default?
You can only define default cases for case selector inputs supporting case ranges, like integers or strings…
This is a highly unusual request. Why do you need to make "TRUE" (or "FALSE") the default case? What does it even mean? A default case means "this value or anything not covered by other cases", so what does a "TRUE" default value mean? It can't be "FALSE" and it's already "TRUE", and there are no other choices, so there is no value in making a default case for a Boolean choice.
I'd really like to add that if you can explain to us why you need this feature, maybe we can help you find a different way to what you need to do. 🙂
A "default" case is needed (and only makes sense) if there are more possible states than the number of cases.
Examples for case selectors:
Boolean input: 2 possible states, two cases.
I32 input: It is very unlikely that you'll have 2^32 different cases, so you would create cases for the expected values or ranges and a default case for anything else.
String input: Again, infinite input possibilities. We need a default case for anything not mentioned explicitely.
Enum input: If the number of cases matches the number of items, no default is needed. If there are fewer cases than items, we need a default case.
If you really want to get a honorable mention in the Rube Goldberg thread, you could of course do silly things as follows:
@altenbach wrote:
A "default" case is needed (and only makes sense) if there are more possible states than the number of cases.
Examples for case selectors:
Boolean input: 2 possible states, two cases.
I32 input: It is very unlikely that you'll have 2^32 different cases, so you would create cases for the expected values or ranges and a default case for anything else.
String input: Again, infinite input possibilities. We need a default case for anything not mentioned explicitely.
Enum input: If the number of cases matches the number of items, no default is needed. If there are fewer cases than items, we need a default case.
If you really want to get a honorable mention in the Rube Goldberg thread, you could of course do silly things as follows:
As a side note: When I have a case structure fed by an Enum, I never have a default case. If I add an element to the enum definition, I want that to break everything that I ought to look at.
@paul_cardinale wrote:
As a side note: When I have a case structure fed by an Enum, I never have a default case. If I add an element to the enum definition, I want that to break everything that I ought to look at.
That really depends on the situation. I sometimes have an enum* with dozens of items and a case structure that only does something interesting for exactly one value, but nothing for all others (exactly two cases: (1) Item X, (2) Default). it might be safe to add values to the enum without breaking the code.
*Here I mean "enum" in the most general case (including also e.g. radiobutton controls and tab controls, which both act the same way when wired to a case structure)
@altenbach wrote:
@paul_cardinale wrote:
As a side note: When I have a case structure fed by an Enum, I never have a default case. If I add an element to the enum definition, I want that to break everything that I ought to look at.
That really depends on the situation. I sometimes have an enum* with dozens of items and a case structure that only does something interesting for exactly one value, but nothing for all others (exactly two cases: (1) Item X, (2) Default). it might be safe to add values to the enum without breaking the code.
*Here I mean "enum" in the most general case (including also e.g. radiobutton controls and tab controls, which both act the same way when wired to a case structure)
I've rarely used defaults with enums. Even if I have a lot of items that can go into one case. I will usually explicitly name the items going into that common state.
@billko wrote:
I will usually explicitly name the items going into that common state.
Try that with a case structure wired to the "event type" event data node. You might need a bigger monitor!
As an example, I have an event case with dozens of "value change" and other types, but need to only handle a double-click on a listbox differently, i.e. having a case structure with "listbox double click" and "default" as the only two cases. (as used in this program)
(Yes, this is slightly different because we have no control over the items. but you might see my point. Without a default case, everything would break if NI decides to add a new event type in 2050 :D)
(Image truncated. the list is much longer!)
