Leaderboard

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.

I can't speak for anyone else, but if I'm trying to change the output of a sub vi based on how (or if) downstream code is using it, that's a pretty good indicator something is wrong with my design. The easiest solution is to refactor the sub vi into smaller functional parts. Clearly the existing one is doing too much stuff in one step. I posted this comment on the NI forum as well, but this thread is getting more activity:

Democracy is two wolves and a sheep deciding what's for dinner. Good thing NI isn't a democracy.

...but what about the use case that spawned this thread: not doing a bunch of extra work if the output of that work isn't even wired? Any ideas on how to do that at teh subVI level? I guess there could always be a ring where the programmer could just select what they do and don't want done, but if only the subVI was aware and could make that decision itself...

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

I have seen this error a few times when the application builder has not managed to successfully built a valid executable but hasn't returned an error either. Last time I saw this error was when there was not enough memory in the build machine for LabVIEW to build a proper executable. As a result the executable didn't really contain anything and the final size of the executable was too small. When executing it, you got this error, which was natural because the executable was corrupted. The problem really was in LV application builder. We fixed the issue first time by getting LabVIEW to address more memory in 32-bit machine during the build and the second time by moving the 32-bit LabVIEW used for building to 64-bit machine.