eventual bug with standard value of strict enum typedef?

[Labuser16383]

Consider the attached vi.

It contains an input element of the type of a strictly typed enum.

You can make a choice and the press "Choosn val" to delegate the choice to the output element

of the same type.

However you can also press "Standardval" to return the standard anyway.

The archive contains both LV2015 and (back converted) LV8 vis.

The problem now is that there seems to be two definitions for "standard value".

1.) The standard value of the underlying type of the strictly typed enum (which is returned when you press  "Standardval")

2.) The standard value of the visible enum object.

The used strictly typed enum was configured to have a standard value of "Choice 3 (Std)" whereas the standard value of the underlying type is
zero.

To return the standard value on pressing the button "Standardval" i configured the connector which leads to the output enum as returning the

standardvalue if not connected.

Surprisingly it does not return the standard value of the enum typedef but the standard value of the underlying type, so the output shows

"Choice 1" instead of "Choice 3 (Std)".

Is this a bug?

In my opinion there should be no ambiguity of the phrase "standard value". If it is used at two places (in this case within the typedef and the context menu of the connector) it should refer to the same value.

Quite naturally a strict typedef should also imply the same for the wire which connects the strict typedef to elsewhere. In nearly every stricly typed language this phrase means that you cannot mix up a "typedef myint of int" and "int" in calculations and function parameter passing. Applied to the example the wire should not behave as holding the enum underlying type but instead like holding the strict type.

Therefore it is quite unfortunate that the connector returns 0 instead of 3 if not connected.

This is my reasoning that the behaviour may be a bug.

[rolfk]

Nope! LabVIEW only applies a user configurable default value to controls (not indicators) on a front panel. When you have a control (input element) on a front panel that is connected to the connector pane and use that VI as subVI, the control will either assume its data default value that you have configured for the control or takes whatever you connect to it on the parent VI diagram. If the control is not connected to the connector pane it will assume on load its configured default value and then maintain whatever value it had between calls to that VI (only really applicable for subVIs that show their front panel so that a user can change that control).

Indicators don't have a user configurable default value and neither have tunnels (the small rectangle on a structure border). For those tunnels when configured to use the default value they will use the LabVIEW default default value which is 0 for numbers, false for booleans, an empty string or array or the canonical NotARefnum constant for refnums. This has been like that since the inception of LabVIEW and is 99.99% unlikely to change now as it would suddenly break lots and lots of code written originally in older versions of LabVIEW.

The default value that you have set in your enum typedef will only be used to apply to controls that you place onto your front panel as initial default value, not as default value everywhere for that datatype.

[Labuser16383]

Yes, from a historical perspective i can agree that leaving everything as it is avoids introducing incompatibilites. But, from a principle point of view,  at least the terminology is not correct if the phrase "default value" is used for both the tunnel default value
and the default item which the strictly typed enum shows by default.

It is very misleading to use the phrase "default value" for something which can assume different values dependent on the circumstance one refers to.

I'm just missing the consequence which is implied by using a strictly defined type and it seems labview developers have a complete own understanding of what is referred to strictly defined types.

Why does a wire knows about its origin strictly defined type when creating an indicator on that wire and on the other hand it forgets about it's origin when one wants to use the default value und then assumes the default of the underlying type? It's really inconsequent.

[rolfk]

The problem is exactly that you talk about the wire knowing about a default value. But a wire knows nothing about a default data value for ANY datatype in LabVIEW. It is the front panel control that maintains a default data value for the case when the front panel is loaded and also when the VI is used as a subVI and that particular connector is not connected by the caller. The typedef editor is simply a special case of a front panel and while you can define a default data value for it LabVIEW will only use that value when you place an instance of that typedef on a front panel, and will then assign the default data value of that control.

I can understand what you want to have and there is some merit to that idea but there are also drawbacks. LabVIEW is visual programming and there is no easy way to visualize that an unwired tunnel will cause a particular value other than the default default type to be propagated to the wire. On the other hand it is a matter of one right mouse click on the tunnel and select Create Constant from there to have a copy of the typedef being created which then will use your default data value as initial value.

[Christoph_D]

Hi Labuser,

I completely agree with Rolf (usally it is the right thing to do with him ) also from the offical NI viewpoint.

You can probably think of many scenarios, where a default value different from the first enum value respectively "0" could cause problems. A tunnel could be connected to different kinds of enums or "normal" integers. Then it would be hard to see which value to expect.

In the end a enum is a integer (with additional information and sequential values) and a integer has a default value of 0.

Perhaps you could do your example the same way with a integer control with a non-zero control default value. The tunnel would also return tunnel default value of zero.

Best regards,

Christoph