Do subVI property nodes force the FP into memory?

[crelf]

A question from the twittersphere:

if i run a subVI containing a property node, is always the subVI front panel going to be loaded in memory?

[Darin]

Not that this level of documentation is always accurate, I usually rely on the Detailed Help for a given property, one of the characteristics listed in the table is "Loads the front panel into memory".

[crelf]

It depends on the type of property node you're talking about - there is no blanket yes or no answer to this. Darin's tight - check the context help for hte properties you're interested in.

[2m_marco]

ok, so this statement I've found in a CLAD exam format:

" The Property nodes contained in a SubVI always cause the front panel to be loaded in memory"

is False. Am I right?

[crelf]

"The Property nodes contained in a SubVI always cause the front panel to be loaded in memory" is False. Am I right?

False is correct.

[TomOrr0W]

By any chance are you refering to the following question (copied from the CLAD Sample Exam 1)?

3. Which of the following apply to Property Nodes? (More than one answer may apply.)

a. Property Nodes allow attributes of front panel objects to be programmatically manipulated.

b. Property Nodes can be used to update the values contained in a front panel object.

c. More than one Property Node can be used for a single front panel object.

d. Property Nodes contained in a SubVI will always cause the front panel to be loaded in memory.

3. Correct Answer: A, B, C, D

Topic: Property Nodes Justification: All of the statements are true for Property Nodes. References: Property Node

[Yair]

False is indeed correct*

That said, If you create a static property node for a control on the front panel, the front panel will always be loaded. This has actual value because when you build an application, the default behavior for most subVIs is to have their front panel removed and there are certain VIs where creating a property node is the easiest way to force LV to keep the FP.

* Although, with the history of the CLAD questions, it's quite possible that the expected answer is not false because of what's in the second paragraph

[mje]

False is indeed correct*

That said, If you create a static property node for a control on the front panel, the front panel will always be loaded. This has actual value because when you build an application, the default behavior for most subVIs is to have their front panel removed and there are certain VIs where creating a property node is the easiest way to force LV to keep the FP.

(Emphasis added)

Indeed Yair is correct from what I've learned. Having a property node which operates on an arbitrary control refnum (that is where you explicitly wire the refnum into the node) does not force the front panel into memory because the refnum being operated on might not even be for a control in the same VI.

[Darin]

Of course the sample questions are skewed and slightly screwed up to begin with. Let's add a philosophical question. Assume you know the truly correct answer, and that it is different than the one you assume NI is looking for. Do you mark the correct answer on principle and lose the points, or do you choose the answer NI is looking for?

I usually choose the former, but I am also inclined to rouse rabble. (If I ever found myself taking the CLAD I'd also like to think that one or two questions would not be making a difference).

[crelf]

Let's add a philosophical question. Assume you know the truly correct answer, and that it is different than the one you assume NI is looking for. Do you mark the correct answer on principle and lose the points, or do you choose the answer NI is looking for?

That depends on your aim: to be correct, or to acheive certification.

[GregR]

There are other sweeping statements that are sometimes heard about property nodes that are not completely true (or sufficiently accurate). The main problem with all these statements is that it is largely not the node that defines the behavior but the reference type the node is being used on. If you look at the "Select Class..." context menu on the property node, its first level shows the major categories of classes.

"Property nodes always run in the UI thread" -- false

"Property nodes for controls always run in the UI thread" -- true

Anything under the "VI Server" category will always run in the UI thread. This includes VI references, Application references and all panel/diagram object references. If you are making a lot of these calls, you might consider moving them to a subVI that can be set to run in the UI thread. Other categories, like VISA, will use any thread. ActiveX has its own rules for which objects can be accessed from which threads. (If you don't have to know about apartments, trust me you don't want to.)

"Any control reference causes the panel of the VI containing the control to be loaded" -- true

"Any control reference will cause the panel of the VI containing the control to be included in built applications" -- false

This is related to the earlier comment about the documentation "Loads the front panel into memory" characteristic. This means that when the operation runs it forces the panel to be loaded. This is different than things that cause the panel to be loaded immediately when the VI is loaded, which is different than things that cause the application builder to include the panel by default.

LabVIEW cannot give you a reference to any part of a panel without loading the entire panel, but there are multiple ways of obtaining control references. Reading the Panel property from a VI reference allows you to get to control references and causes the panel to be dynamically loaded if it is not already in memory. If the panel is not available, then an error is produced at run time. This is different than getting a control reference from a control reference constant. These are detected by LabVIEW causing it to load the panel as part of loading the VI. This means the VI is never in memory without its panel. This is also the case for implicitly linked property nodes (ones tied statically to a control and with their reference input hidden).

The application builder uses the presence of control reference constants or implicitly linked property nodes as a sign that the panel must be included. However there are also other things that it looks at. Most of the Window Appearance settings for a VI being changed from the default will also tell the application builder to include the panel. The logic is that if you customized the look of the VI window, it is probably because you plan to show that window to the user. So instead of creating a implicit property node or control reference constant to get a panel included in a build, you could hide the panels scroll bars.

[2m_marco]

Thank you all guys, very interesting discussion

@GregR great !

[Yair]

So instead of creating a implicit property node or control reference constant to get a panel included in a build, you could hide the panels scroll bars.

With one important difference - it's much easier to document why you have an unused property by placing a comment next to it than to safely document why the scroll bars are hidden (safely = in a way which will make it unlikely that someone will accidentally change it).

[asbo]

With one important difference - it's much easier to document why you have an unused property by placing a comment next to it than to safely document why the scroll bars are hidden (safely = in a way which will make it unlikely that someone will accidentally change it).

Having to do workarounds like this makes me wonder why a VI property isn't added to force a FP to be included. Is it just a legacy thing or is there a technical reason?

[Yair]

Having to do workarounds like this makes me wonder why a VI property isn't added to force a FP to be included.

There's certainly no technical reason. I'm guessing that no one ever thought of it, because usually it's not needed (i.e. either the VI doesn't need its FP or it has the FP included due to the normal configuration of the code, such as having the FP set to open when called).

The build configuration dialog does allow you to override the remove-FP setting for every VI, but I don't like that, because it's very hidden and you have to set it for each build separately. If you add an idea for such a VI property to the IE I would certainly vote for it.

[Yair]

OK, I added an idea for this - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-property-to-guarantee-that-the-front-panel-of-a-VI-will/idi-p/1779268

[asbo]

Thanks - kudos'd.