Scripting: Input Tunnels Use Default Value Always TRUE on Event Structures

[StefanLemmens]

When I was testing this VI Analyzer test I noticed something strange on event structures.

The input tunnels for event structures and cases are also conditional tunnels. I understand that the output tunnels of these structures are conditional but don't see why the input tunnels are of the type conditional tunnel.

The problem however is that for event structures the property "UseDefault" is always TRUE. On output tunnels this property can be defined by the developer in the right-click menu "Use Default If Unwired". For input tunnels however this property can not be changed, even more it has no use since there is always a wire connected on the outer terminal to define the value. For case structures the property "UseDefault" is always FALSE for input tunnels, which is better.

The above mentioned VI Analyzer test gives incorrect warnings if a tunnel is unwired on the inside of an event structure.

Remarks :

• Why are input tunnels on event structures and case structure of the type "ConditionalTunnel"?
• Why have input tunnels on event structures the property "UseDefault" set to TRUE?

I tested this with LabVIEW 2013, 2016 and 2018.

2013 version is attached.

Best Regards,

Stefan Lemmens

Intersoft Electronics

[ikaiser]

Hello Stefan!

I am not sure if I understand the core of your question. I'll try:

Why are input tunnels on event structures and case structure of the type "ConditionalTunnel"?

---

My interpretation is that this is simply the GObject name of an even or case structure's input tunnel. In contrast, loop tunnels are called LoopTunnel, and loop output tunnels set to conditional are LoopTunnel objects with property Is Conditional? set to true.

So yes, it's unaesthetic that input tunnels of event structures are called ConditionalTunnel internally while conditional loop output tunnels are called "conditional tunnel" in normal language.

Does this explanation make sense to you?

Why have input tunnels on event structures the property "UseDefault" set to TRUE?

---

Very good question. I'd guess it is random. Event/case structure input tunnels need to be connected to a data source. In my understanding the UseDefault property does not apply to them, so neither false nor true makes any sense.

By the way, the VI Analyzer you linked was fixed to not provide a warning anymore.

[StefanLemmens]

Hello Ingo,

your explanation about why these tunnels are named conditional tunnels does make sense to me. It's indeed just because they are connected to a conditional structure. Hadn't thought about that.

It would have been better if the UseDefault property was set to false in those cases where it is not applicable. An inapplicable true is just more confusing.

Thanks for your answer.

Best Regards,

Stefan

[ikaiser · Accepted solution]

Hello Stefan,

---

It would have been better if the UseDefault property was set to false in those cases where it is not applicable. An inapplicable true is just more confusing.

---

At first I fully agreed. I had already typed the bug report, when I started to ponder again and maybe found a god explanation:

Event Structure outputs are set to "Use Default If Unwired" by default. Case Structure outputs are not. Internally, input and output tunnels seem to be the same - if they are an input or output (source or sink) seems to be derived from what is connected to them.

This way it makes sense (at least to me ) that Event Structure inputs have UseDefault set to true - otherwise LabVIEW would not know which state to use when an output was converted to an input and back.

I adapted the VIs you posted to briefly check if the current tunnel is an input or output (I believe this is an approach similar to the one the VI tester you linked uses):

(Attached in LV18 and LV13)

Of course, LabVIEW IDE could implement hidden logic to (re-)set inputs to UseDefault=false, but I believe such hidden features would confuse more than the current unexpected but logic structure.

[Kyle97330]

Somewhat unrelated to the actual issue, just a FYI that you don't need to close the references to the tunnels.  Any "Close reference" that runs on any descendant of GObject is a no-op if a "close reference" is called on it.

For more info, check out "An end to brainless LabVIEW programming" by NI's own Darren Nattinger.

Scripting already makes incredibly long horizontal block diagrams, there's no need to pad it out further...

[StefanLemmens]

Hi Ingo,

thanks for your explanation. It's good to know that there is at least a reason why things are the way they are.

Best Regards

Stefan

[ikaiser]

Kyle, thank you for the good video link!

(Point taken. I though about the close reference nodes but did not think far enough. Definitely brainless^^)