04-22-2025 05:01 PM - edited 10-30-2025 10:21 AM
In LabVIEW 2025 Q3, when placing a Diagram Disable Structure to enclose a section of code, LabVIEW will match output tunnels with input tunnels to wire values through in the Enabled frame by default. If LabVIEW is not able to find the source for a refnum or LabVIEW class output tunnel, the tunnel will not be configured with “Use Default if Unwired.”
[Idea submitted by NI Discussion Forums member Jim_Kring.]
10-24-2025 09:45 AM
Hi Christina,
After testing a bit this new feature, I noticed some unexpected behaviors (at least to me) with the automatic finding of matching inputs.
1. It does not seem to work when enclosing certain structure types:
Example by disabling a Case Structure:
Here it found none of the matching inputs.
It does the same when enclosing another Diagram Disable Structure, a Type Specialization Structure or a Multi-Frame Stacked Sequence Structure.
I would expect it to work regardless of the code that needs to be disabled.
2. Another issue is with multiple inputs/outputs of the same data type:
Example with two I32 inputs and two I32 outputs:
Here it matched all I32 outputs to a single I32 input.
I would expect it to:
- either be "smart" and find matching sources based on tunnel vertical position (or whatever other logic);
- or decide that it cannot make a choice and let the user do the wiring (and especially NOT marking the tunnels as "Use Default If Unwired").
3. A last smaller issue is the fact that the tunnels are marked "Use Default If Unwired" even if a matching input is found. I would prefer the IDE to use this flag as little as possible. If for example we add a frame later, we may forget to wire them through.
Attached is a VI that demonstrates these behaviors.
Regards,
Raphaël.
11-04-2025 11:13 AM
Thanks for working on this!
Note: I haven't finished my coffee yet, so this may come across as overly grumpy :))
I believe that this feature needs to be 100% deterministic that an output terminal has one and only one possible data source. Otherwise, leave that output terminal unwired.
For what it's worth, the original idea I posted was to Not Use Default Values for Unwired Output Tunnels.
The crux of this request is that outputs using default values causes unintended bugs.
The new new Preserve Values by Default feature, in my opinion, could potentially take us from the "relatively simple" kind of bugs, into a more dangerous zone of "extremely complex and hard to find" bugs (as is evidenced by the feedback so far around failed corner cases).
I understand the complexities of graph traversal (for type and dataflow propagation at edit-time), so I can both appreciate how hard people probably worked on this feature, yet also how hard it is to get 100% right.
So, while I like the spirit of this feature, I think that if not 100% bullet-proof, would go against the grain of my initial idea and possibly take us a step back.
I would still very much want a feature to simply turn off any kind of default values or algorithmic guesswork around the dataflow (unless it's 100% deterministic that an output has one and only one possible data source), so I can simply make these decisions for myself.
PS - I dug up my old blog post about this here.
11-16-2025 01:13 PM
@Christina_R Should I make a service request about these unexpected behaviors or does a CAR number already exist?
11-17-2025 10:06 AM
I've brought your feedback to the attention of the LabVIEW development team, but what you're requesting is a feature and not a bug fix.
Our goal for the LabVIEW 2025 Q3 feature was to help developers more quickly get from the placement of a Diagram Disable structure to the code they want in their enabled frame.
We turned off "Use Default if Unwired" on refnums and classes because we agreed that the default value for these types never made sense. But for other data types, default values are often acceptable.
For cases where LabVIEW matches input and output tunnels incorrectly, users should edit the code to their desired results.
I can see why you want a feature that forces the user to wire every output, to further minimize the chances of an unintended output value. But the usability trade-off is that it will take longer to disable a section of code.
11-17-2025 11:26 AM
@Christina_R wrote:
I've brought your feedback to the attention of the LabVIEW development team, but what you're requesting is a feature and not a bug fix.
That's fair.
If you can, please don't mark the idea exchange post as "completed" or associate "Preserve Values by Default When Placing Diagram Disable Structures" with it, since "Preserve Values by Default..." is counter to the original feature request, and I'd still like to be able to advocate for it.
Thanks.