Putting a disable structure around a typedef front panel node on the block diagram shouldn't require the typedef to be loaded

[crelf]

Scenario: I have a section of code that has missing subVIs and controls (they're typedefs), and I want to disable it.  I put a diagram disable structure around the code, and it means that the missing VIs are okay, but LabVIEW still requires the typedef'd controls to be loaded <- this causes a broken arrow, even through the only broken code is within the diagram disable structure.

Fix: If the only reference to a typedef control is within the disabled case of a diagram disabled structure, then it should be ignored (and therefore should have to be loaded).

[kegghead]

Agreed. Seems like a glaring omission to me, I'm surprised to learn this isn't already the case.

[SteenSchmidt]

This omission is also the reason several VIs in the Simulation Interface Toolkit are broken. As it is today you'll need to manually change some of these VIs to be able to build an application that uses SIT. The diagram disable structure needs to move forward in the (pre)compiler bus. Kudos from me.

[smercurio_fc]

I'm wondering if this should be categorized as a bug as opposed to an idea.

[AristosQueue (NI)]

If it is a typedef control, that's correct behavior -- the control is still on the panel, it's still live, and you might be referencing it through a control refnum.

If it is a typedef constant, LabVIEW does leave out the reference already.

So, either this should be closed as "Correct Behavior" or "Already Implemented." Which would you prefer?

[AristosQueue (NI)]

PS: Suggesting a whole new idea that is something like "diagram disable structure around the FPTerminal of a control should hide the control on the panel, break all local variables and property nodes that are statically linked to that control (unless they're also inside the diagram disable structure), and remove that control from the list of control refnums returned when the panel is asked at runtime for its list of controls, and break the VI if that control is on the conpane" would be ok. As long as we're clear that we're talking about a much wider ranging feature.

[Darin.K]

I would probably prefer a method of temporarily disconnecting all controls and constants in a VI from their TypeDef and then automatically reconnecting when testing is finished.

[rgvdh@rdf]

Crelf: "If the only reference to a typedef control is within the disabled case of a diagram disabled structure, then it should be ignored (and therefore should['nt] have to be loaded)."

Aristos Queue: "If it is a typedef control, that's correct behavior -- the control is still on the panel, it's still live, and you might be referencing it through a control refnum."

But if you're not referencing it through a control refnum it isn't doing anything and can have no effect on program execution.

Would it be possbile for the compiler to figure out when it's not referenced via refnum? 

In that case, don't ask to load it, and on the front panel put either nothing or some sort of placeholder object.

[crelf]

smercurio_fc: I'm wondering if this should be categorized as a bug as opposed to an idea.

No, as AQ points out, it's not a bug - it's a behavior change request (see Imago)

rgvdh@rdf: Would it be possbile for the compiler to figure out when it's not referenced via refnum?

A static reference is only one case where this would fail - there's loose references (Val.Set through VI Server) that wouldn't work either.

AQ: either this should be closed as "Correct Behavior" or "Already Implemented." Which would you prefer?

I'd prefer "We can do better". 🙂  I agree that the "diagram disable structure around the FPTerminal of a control should hide the control on the panel, break all local variables..." is more accurate, although I don't think the control should be hidden - disabled and grayed: yes, hidden: no.

[AristosQueue (NI)]

So, assumming that this idea is actually retitled as "Diagram Disable structure around an FPTerminal should effectively remove the control from participating in the running VI", let's list all the things that would need to happen:

1. The VI would not load any typedef, XControl, ActiveX and/or LVClass connected to the disabled control.
2. The control on the panel would need to draw differently. I would vote for "completely hidden". After all, the control is potentially stale so even drawing it grayed out it may not be drawing the right thing, and if it is a UI element that isn't actually implemented, it seems better to not show it at all in my panel. It would, IMHO, make this feature more useful for commenting out a feature, like a checkbox whose functionality isn't yet implemented.
3. Any Value property nodes strictly bound to the control and any local variables of the control that are not inside disabled diagrams should be broken.
4. It should be impossible to get a control reference to the disabled control. Asking the VI for a list of all of its controls should not include this control in the list. All other mechanisms for getting a reference to that control should fail. This would make the "completely hidden" more important since there'd be no programmatic way to manipulate the control to move it around in a visual layout.
5. What do we do if the control is on the conpane? We could do nothing -- an input terminal is ignored, and output terminals produce default values. We could break the VI. We could leave the control on the conpane but have that terminal not show up on caller diagrams. I lean toward "do nothing", but I'm open to arguments.

Anything else?

[crelf]

Thinking about this a little more: I'm not sure I want the property nodes outside of the disable structure breaking.  I mean, maybe I do if it's a typedef, but not if it's a normal control.  Also, I agree that I want to do nothing if the terminal is on the conpane, but maybe we can use the same argument to do nothing if the terminal has property nodes.