Lessons learned from plugins - Revision history

TiT: correct capitalization of LabVIEW

2008-09-08T08:53:36Z

correct capitalization of LabVIEW

← Older revision		Revision as of 08:53, 8 September 2008
Line 1:		Line 1:
	When launching ~~LabView~~ VIs using VI Server, the intrepid programmer may run across some stumbling blocks. Below is a collection of issues that Jova Solutions documented while implementing a method to allow users of a built ~~LabView~~ executable to have their own ~~labview~~ code run by the executable. This information was collected while working in ~~LabView~~ 6.1 and 7.0, and is valid for 7.1 as well, according to NI Developers. We welcome input from groups working in 8.0 or higher.		When launching LabVIEW VIs using VI Server, the intrepid programmer may run across some stumbling blocks. Below is a collection of issues that Jova Solutions documented while implementing a method to allow users of a built LabVIEW executable to have their own LabVIEW code run by the executable. This information was collected while working in LabVIEW 6.1 and 7.0, and is valid for 7.1 as well, according to NI Developers. We welcome input from groups working in 8.0 or higher.

	== Facts about App, VI, and Control References ==		== Facts about App, VI, and Control References ==
Line 9:		Line 9:
	* Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.		* Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.
	* Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.		* Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.
	* Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property. (According to LV developer Stephen R. Mercer with a 26 Oct 2007 statement on info-~~labview~~ this is false for LV versions >8.0. Clones of reentrant VIs now have their own panel and diagram, enabling independent VI Server work and independent probes for debugging).		* Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property. (According to LV developer Stephen R. Mercer with a 26 Oct 2007 statement on info-LabVIEW this is false for LV versions >8.0. Clones of reentrant VIs now have their own panel and diagram, enabling independent VI Server work and independent probes for debugging).

	== To avoid problems with references ==		== To avoid problems with references ==

Michael_Aivaliotis: added category

2007-10-29T06:28:00Z

added category

← Older revision		Revision as of 06:28, 29 October 2007
Line 40:		Line 40:
	[b]Meg Kay[/b] and [b]Veda Murthy[/b] of Jova Solutions, Inc.<br />		[b]Meg Kay[/b] and [b]Veda Murthy[/b] of Jova Solutions, Inc.<br />
	June 26, 2002		June 26, 2002
			[[category:Calling a VI]]

Michael_Aivaliotis: cleaned up style issues.

2007-10-29T06:25:47Z

cleaned up style issues.

← Older revision		Revision as of 06:25, 29 October 2007
Line 1:		Line 1:
	When launching LabView VIs using VI Server, the intrepid programmer may run across some stumbling blocks. Below is a collection of issues that Jova Solutions documented while implementing a method to allow users of a built LabView executable to have their own labview code run by the executable. This information was collected while working in LabView 6.1 and 7.0, and is valid for 7.1 as well, according to NI Developers. We welcome input from groups working in 8.0 or higher.~~<br />~~		When launching LabView VIs using VI Server, the intrepid programmer may run across some stumbling blocks. Below is a collection of issues that Jova Solutions documented while implementing a method to allow users of a built LabView executable to have their own labview code run by the executable. This information was collected while working in LabView 6.1 and 7.0, and is valid for 7.1 as well, according to NI Developers. We welcome input from groups working in 8.0 or higher.

	1. Facts about App, VI, and Control References~~:<br />~~		== Facts about App, VI, and Control References ==
	* You cannot test an Application Refnum using Not-A-Refnum; you must try using it, e.g. read the Name property and test the error returned. This is time-consuming (?).<br />
	* Opening Application Ref with default empty string (local machine) uses ActiveX for VI Server functions (ActiveX must be enabled in Options -> VI Server: Configuration, Protocols). Opening Application Ref with any string input, including local machine name instead of default empty string uses TCPIP for VI Server functions (TCPIP must be enabled in Options -> VI Server: Configuration, Protocols). Using TCPIP VI Server functions is slower than using ActiveX; so always use empty string instead of local machine name.<br />
	* Opening VI Refs - benchmarks (non-reentrant faster to open than reentrant, untyped faster than typed, ...)<br />
	* VI Reference will become invalid (disposed by LV) when call chain of VI that opened the reference finishes running. The VI that opened the reference might still be in memory and reserved by a different caller, but that doesn't keep original caller's references valid.<br />
	* Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.<br />
	* Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.<br />
	* Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property. (According to LV developer Stephen R. Mercer with a 26 Oct 2007 statement on info-labview this is false for LV versions >8.0. Clones of reentrant VIs now have their own panel and diagram, enabling independent VI Server work and independent probes for debugging).<br />

	2. ~~To avoid problems with references:<br />~~		* You cannot test an Application Refnum using Not-A-Refnum; you must try using it, e.g. read the Name property and test the error returned. This is time-consuming (?).
	* Test AppRef by reading application property~~, such as name~~. This is ~~expensive~~.~~<br />~~		* Opening Application Ref with default empty string (local machine) uses ActiveX for VI Server functions (ActiveX must be enabled in Options -> VI Server: Configuration, Protocols). Opening Application Ref with any string input, including local machine name instead of default empty string uses TCPIP for VI Server functions (TCPIP must be enabled in Options -> VI Server: Configuration, Protocols). Using TCPIP VI Server functions is slower than using ActiveX; so always use empty string instead of local machine name.
	* ~~Always use~~ empty string ~~to open an AppRef to the~~ local LV, instead of ~~the~~ local machine name.~~<br />~~		* Opening VI Refs - benchmarks (non-reentrant faster to open than reentrant, untyped faster than typed, ...)
	* ~~Open and manage~~ VI ~~refs in independent~~ VI that ~~stays~~ running ~~for~~ the ~~life of the application~~.~~<br />~~		* VI Reference will become invalid (disposed by LV) when call chain of VI that opened the reference finishes running. The VI that opened the reference might still be in memory and reserved by a different caller, but that doesn't keep original caller's references valid.
	* ~~Preload VIs using PATH as early as possible and keep that initial~~ reference open ~~so VI stays in memory (~~non-reentrant because ~~faster to open; won~~'~~t be used~~ to ~~call~~ VI), ~~then~~ any ~~subsequent Open of untyped~~ reentrant VI ~~refs~~ can use ~~STRING name input.<br />~~		* Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.
	* Use Get/SetControlValue ~~instead of~~ Value property for ~~controls on~~ reentrant VI.~~<br />~~		* Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.
			* Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property. (According to LV developer Stephen R. Mercer with a 26 Oct 2007 statement on info-labview this is false for LV versions >8.0. Clones of reentrant VIs now have their own panel and diagram, enabling independent VI Server work and independent probes for debugging).

	~~3. Facts about LV Execution: the [b]Root Loop[/b]<br />~~		== To avoid problems with references ==
	* The LV execution system processes certain user interface activity in sequential order in "root loop."<br />
	* User activity can block the root loop for long periods, such as a LV dialog box and menu navigation. Whenever our application uses LV functions that go through the root loop, it will be blocked (hang) until the user activity completes. If a user leaves a menu open and then goes home for the weekend, it's possible to hang every station on the network.<br />
	* Opening untyped VI ref with ~~PATH input type goes through root loop; opening untyped VI ref with STRING input type does not go through root loop.<br />~~
	* Open TYPED VI reference always goes through root loop (regardless of path or string input).<br />
	* Invoking the Run method on a VI goes through the root loop (think of this as programmatically pressing the Run button).<br />
	* Invoking the Abort method on a VI goes through the root loop (think of this as programmatically pressing the Abort button). When you close the last reference to a VI so it drops out of memory, it will also abort, but this does not involve the root loop.<br />

	4. To avoid problems with the root loop~~:<br />~~		* Test AppRef by reading application property, such as name. This is expensive.
	* Do not use LV built-in dialogs; use dialog-mode subVI.~~<br />~~		* Always use empty string to open an AppRef to the local LV, instead of the local machine name.
	* Open TYPED VI reference as early as possible.~~<br />~~		* Open and manage VI refs in independent VI that stays running for the life of the application.
	* Use call by reference instead of using Run method whenever possible. Not possible if caller should not wait for other VI to finish (Wait until Done option only on Run method).~~<br />~~		* Preload VIs using PATH as early as possible and keep that initial reference open so VI stays in memory (non-reentrant because faster to open; won't be used to call VI), then any subsequent Open of untyped reentrant VI refs can use STRING name input.
	* To use call by reference for Vis with different, unknown connector panes, use Get/SetControlValue methods to set inputs & outputs instead of wiring to connector pane in Call by Ref; and force Vis to conform to "blank" connector pane (this can be set programmatically).~~<br />~~		* Use Get/SetControlValue instead of Value property for controls on reentrant VI.
	* To keep VI Refs valid for as long as possible, we launch a looping VI that takes requests off a queue and opens ALL the VI refs for our application (both local and remote refs).~~<br />~~
	* We need to know if a VI that we have started running in the background (not waiting until done) has finished. We have the reentrant reference to the VI; but the property "VI state" does not distinguish between running and reserved. We considered closing this reentrant reference as the last thing in the running VI itself (which would abort it) so that we could know the VI was complete if the reference was invalid. However, if a VI (or one of its subVIs) closes its own reentrant reference, LV 6.1 will crash. So we had to set a Boolean control on the Vi's front panel to True as the first thing in the VI's code and to False as the last thing. The application can read this Boolean (must use GetControlValue method, not Value property) to find out if the VI is running.~~<br />~~		== Facts about LV Execution: the [b]Root Loop[/b] ==
	* Catch 22: VI Refs Fact (d) vs. Root Loop Facts (e & f). If we might need to abort a VI that we have started running in the background, we have to use the Run method to start it, so we can't avoid going through the root loop then. But we can close its (reentrant) reference instead of using the Abort method to avoid the root loop there.~~<br />~~
			* The LV execution system processes certain user interface activity in sequential order in "root loop."
			* User activity can block the root loop for long periods, such as a LV dialog box and menu navigation. Whenever our application uses LV functions that go through the root loop, it will be blocked (hang) until the user activity completes. If a user leaves a menu open and then goes home for the weekend, it's possible to hang every station on the network.
			* Opening untyped VI ref with PATH input type goes through root loop; opening untyped VI ref with STRING input type does not go through root loop.
			* Open TYPED VI reference always goes through root loop (regardless of path or string input).
			* Invoking the Run method on a VI goes through the root loop (think of this as programmatically pressing the Run button).
			* Invoking the Abort method on a VI goes through the root loop (think of this as programmatically pressing the Abort button). When you close the last reference to a VI so it drops out of memory, it will also abort, but this does not involve the root loop.

			== To avoid problems with the root loop ==

			* Do not use LV built-in dialogs; use dialog-mode subVI.
			* Open TYPED VI reference as early as possible.
			* Use call by reference instead of using Run method whenever possible. Not possible if caller should not wait for other VI to finish (Wait until Done option only on Run method).
			* To use call by reference for Vis with different, unknown connector panes, use Get/SetControlValue methods to set inputs & outputs instead of wiring to connector pane in Call by Ref; and force Vis to conform to "blank" connector pane (this can be set programmatically).
			* To keep VI Refs valid for as long as possible, we launch a looping VI that takes requests off a queue and opens ALL the VI refs for our application (both local and remote refs).
			* We need to know if a VI that we have started running in the background (not waiting until done) has finished. We have the reentrant reference to the VI; but the property "VI state" does not distinguish between running and reserved. We considered closing this reentrant reference as the last thing in the running VI itself (which would abort it) so that we could know the VI was complete if the reference was invalid. However, if a VI (or one of its subVIs) closes its own reentrant reference, LV 6.1 will crash. So we had to set a Boolean control on the Vi's front panel to True as the first thing in the VI's code and to False as the last thing. The application can read this Boolean (must use GetControlValue method, not Value property) to find out if the VI is running.
			* Catch 22: VI Refs Fact (d) vs. Root Loop Facts (e & f). If we might need to abort a VI that we have started running in the background, we have to use the Run method to start it, so we can't avoid going through the root loop then. But we can close its (reentrant) reference instead of using the Abort method to avoid the root loop there.

	[b]Meg Kay[/b] and [b]Veda Murthy[/b] of Jova Solutions, Inc.<br />		[b]Meg Kay[/b] and [b]Veda Murthy[/b] of Jova Solutions, Inc.<br />
	June 26, 2002		June 26, 2002

Urs Lauterburg at 13:06, 27 October 2007

2007-10-27T13:06:22Z

← Older revision		Revision as of 13:06, 27 October 2007
Line 8:		Line 8:
	* Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.<br />		* Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.<br />
	* Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.<br />		* Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.<br />
	* Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property. (According to LV developer Stephen R. Mercer with a 26 Oct 2007 statement on info-labview this is false for LV versions >8.0. Clones of reentrant VIs now have their		* Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property. (According to LV developer Stephen R. Mercer with a 26 Oct 2007 statement on info-labview this is false for LV versions >8.0. Clones of reentrant VIs now have their own panel and diagram, enabling independent VI Server work and independent probes for debugging).<br />
	own panel and diagram, enabling independent VI Server work and independent
	probes for debugging).<br />

	2. To avoid problems with references:<br />		2. To avoid problems with references:<br />

Urs Lauterburg at 13:05, 27 October 2007

2007-10-27T13:05:39Z

← Older revision		Revision as of 13:05, 27 October 2007
Line 8:		Line 8:
	* Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.<br />		* Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.<br />
	* Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.<br />		* Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.<br />
	* Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property.<br />		* Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property. (According to LV developer Stephen R. Mercer with a 26 Oct 2007 statement on info-labview this is false for LV versions >8.0. Clones of reentrant VIs now have their
			own panel and diagram, enabling independent VI Server work and independent
			probes for debugging).<br />

	2. To avoid problems with references:<br />		2. To avoid problems with references:<br />

Andrewjohnson at 23:11, 26 October 2007

2007-10-26T23:11:30Z

Andrewjohnson at 23:07, 26 October 2007

2007-10-26T23:07:22Z

Andrewjohnson at 22:57, 26 October 2007

2007-10-26T22:57:35Z

Andrewjohnson: Lessons from a project that make extensive use of call VI by reference. Cautions regarding LabView's "Root Loop"

2007-10-26T22:55:06Z

Lessons from a project that make extensive use of call VI by reference. Cautions regarding LabView's "Root Loop"

New page

When launching LabView VIs using VI Server, the intrepid programmer may run across some stumbling blocks. Below is a collection of issues that Jova Solutions documented while implementing a method to allow users of a built LabView executable to have their own labview code run by the executable. This information was collected while working in LabView 6.1 and 7.0, and is valid for 7.1 as well, according to NI Developers. We welcome input from groups working in 8.0 or higher.

1. Facts about App, VI, and Control References:
a. You cannot test an Application Refnum using Not-A-Refnum; you must try using it, e.g. read the Name property and test the error returned. This is time-consuming (?).
b. Opening Application Ref with default empty string (local machine) uses ActiveX for VI Server functions (ActiveX must be enabled in Options -> VI Server: Configuration, Protocols). Opening Application Ref with any string input, including local machine name instead of default empty string uses TCPIP for VI Server functions (TCPIP must be enabled in Options -> VI Server: Configuration, Protocols). Using TCPIP VI Server functions is slower than using ActiveX; so always use empty string instead of local machine name.
c. Opening VI Refs - benchmarks (non-reentrant faster to open
than reentrant, untyped faster than typed, ...)
d. VI Reference will become invalid (disposed by LV) when call chain of VI that opened the reference finishes running. The VI that opened the reference might still be in memory and reserved by a different caller, but that doesn't keep original caller's references valid.
e. Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.
f. Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.
g. Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property.

2. To avoid problems with references:
a. Test AppRef by reading application property, such as name. This is expensive.
b. Always use empty string to open an AppRef to the local LV, instead of the local machine name.
c. Open and manage VI refs in independent VI that stays running for the life of the application.
d. Preload VIs using PATH as early as possible and keep that initial reference open so VI stays in memory (non-reentrant because faster to open; won't be used to call VI), then any subsequent Open of untyped reentrant VI refs can use STRING name input.
e. Use Get/SetControlValue instead of Value property for controls on reentrant VI.

3. Facts about LV Execution: the [b]Root Loop[/b]
a. The LV execution system processes certain user interface activity in sequential order in "root loop."
b. User activity can block the root loop for long periods, such as a LV dialog box and menu navigation. Whenever our application uses LV functions that go through the root loop, it will be blocked (hang) until the user activity completes. If a user leaves a menu open and then goes home for the weekend, it's possible to hang every station on the network.
c. Opening untyped VI ref with PATH input type goes through root loop; opening untyped VI ref with STRING input type does not go through root loop.
d. Open TYPED VI reference always goes through root loop (regardless of path or string input).
e. Invoking the Run method on a VI goes through the root loop (think of this as programmatically pressing the Run button).
f. Invoking the Abort method on a VI goes through the root loop (think of this as programmatically pressing the Abort button). When you close the last reference to a VI so it drops out of memory, it will also abort, but this does not involve the root loop.

4. To avoid problems with the root loop:
a. Do not use LV built-in dialogs; use dialog-mode subVI.
b. Open TYPED VI reference as early as possible.
c. Use call by reference instead of using Run method whenever possible. Not possible if caller should not wait for other VI to finish (Wait until Done option only on Run method).
d. To use call by reference for Vis with different, unknown connector panes, use Get/SetControlValue methods to set inputs & outputs instead of wiring to connector pane in Call by Ref; and force Vis to conform to "blank" connector pane (this can be set programmatically).
e. To keep VI Refs valid for as long as possible, we launch a looping VI that takes requests off a queue and opens ALL the VI refs for our application (both local and remote refs).
f. We need to know if a VI that we have started running in the background (not waiting until done) has finished. We have the reentrant reference to the VI; but the property "VI state" does not
distinguish between running and reserved. We considered closing this reentrant reference as the last thing in the running VI itself (which would abort it) so that we could know the VI was complete if the reference was invalid. However, if a VI (or one of its subVIs) closes its own reentrant reference, LV 6.1 will crash. So we had to set a Boolean control on the Vi's front panel to True as the first thing in the VI's code and to False as the last thing. The application can read this Boolean (must use GetControlValue method, not Value property) to find out if the VI is running.
g. Catch 22: VI Refs Fact (d) vs. Root Loop Facts (e & f). If we might need to abort a VI that we have started running in the background, we have to use the Run method to start it, so we can't avoid going through the root loop then. But we can close its (reentrant) reference instead of using the Abort method to avoid the root loop there.

Meg Kay and Veda Murthy of Jova Solutions, Inc.
June 26, 2002

← Older revision		Revision as of 23:11, 26 October 2007
Line 1:		Line 1:
	When launching LabView VIs using VI Server, the intrepid programmer may run across some stumbling blocks. Below is a collection of issues that Jova Solutions documented while implementing a method to allow users of a built LabView executable to have their own labview code run by the executable. This information was collected while working in LabView 6.1 and 7.0, and is valid for 7.1 as well, according to NI Developers. We welcome input from groups working in 8.0 or higher.<br />		When launching LabView VIs using VI Server, the intrepid programmer may run across some stumbling blocks. Below is a collection of issues that Jova Solutions documented while implementing a method to allow users of a built LabView executable to have their own labview code run by the executable. This information was collected while working in LabView 6.1 and 7.0, and is valid for 7.1 as well, according to NI Developers. We welcome input from groups working in 8.0 or higher.<br />

	# Facts about App, VI, and Control References:<br />		1. Facts about App, VI, and Control References:<br />
	** a. You cannot test an Application Refnum using Not-A-Refnum; you must try using it, e.g. read the Name property and test the error returned. This is time-consuming (?).<br />		* You cannot test an Application Refnum using Not-A-Refnum; you must try using it, e.g. read the Name property and test the error returned. This is time-consuming (?).<br />
	** b. Opening Application Ref with default empty string (local machine) uses ActiveX for VI Server functions (ActiveX must be enabled in Options -> VI Server: Configuration, Protocols). Opening Application Ref with any string input, including local machine name instead of default empty string uses TCPIP for VI Server functions (TCPIP must be enabled in Options -> VI Server: Configuration, Protocols). Using TCPIP VI Server functions is slower than using ActiveX; so always use empty string instead of local machine name.<br />		* Opening Application Ref with default empty string (local machine) uses ActiveX for VI Server functions (ActiveX must be enabled in Options -> VI Server: Configuration, Protocols). Opening Application Ref with any string input, including local machine name instead of default empty string uses TCPIP for VI Server functions (TCPIP must be enabled in Options -> VI Server: Configuration, Protocols). Using TCPIP VI Server functions is slower than using ActiveX; so always use empty string instead of local machine name.<br />
	** c. Opening VI Refs - benchmarks (non-reentrant faster to open		* Opening VI Refs - benchmarks (non-reentrant faster to open than reentrant, untyped faster than typed, ...)<br />
	than reentrant, untyped faster than typed, ...)<br />		* VI Reference will become invalid (disposed by LV) when call chain of VI that opened the reference finishes running. The VI that opened the reference might still be in memory and reserved by a different caller, but that doesn't keep original caller's references valid.<br />
	** d. VI Reference will become invalid (disposed by LV) when call chain of VI that opened the reference finishes running. The VI that opened the reference might still be in memory and reserved by a different caller, but that doesn't keep original caller's references valid.<br />		* Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.<br />
	** e. Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.<br />		* Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.<br />
	** f. Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.<br />		* Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property.<br />
	** g. Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property.<br />

	# To avoid problems with references:<br />		2. To avoid problems with references:<br />
	** a. Test AppRef by reading application property, such as name. This is expensive.<br />		* Test AppRef by reading application property, such as name. This is expensive.<br />
	** b. Always use empty string to open an AppRef to the local LV, instead of the local machine name.<br />		* Always use empty string to open an AppRef to the local LV, instead of the local machine name.<br />
	** c. Open and manage VI refs in independent VI that stays running for the life of the application.<br />		* Open and manage VI refs in independent VI that stays running for the life of the application.<br />
	** d. Preload VIs using PATH as early as possible and keep that initial reference open so VI stays in memory (non-reentrant because faster to open; won't be used to call VI), then any subsequent Open of untyped reentrant VI refs can use STRING name input.<br />		* Preload VIs using PATH as early as possible and keep that initial reference open so VI stays in memory (non-reentrant because faster to open; won't be used to call VI), then any subsequent Open of untyped reentrant VI refs can use STRING name input.<br />
	** e. Use Get/SetControlValue instead of Value property for controls on reentrant VI.<br />		* Use Get/SetControlValue instead of Value property for controls on reentrant VI.<br />

	# Facts about LV Execution: the [b]Root Loop[/b]<br />		3. Facts about LV Execution: the [b]Root Loop[/b]<br />
	** a. The LV execution system processes certain user interface activity in sequential order in "root loop."<br />		* The LV execution system processes certain user interface activity in sequential order in "root loop."<br />
	** b. User activity can block the root loop for long periods, such as a LV dialog box and menu navigation. Whenever our application uses LV functions that go through the root loop, it will be blocked (hang) until the user activity completes. If a user leaves a menu open and then goes home for the weekend, it's possible to hang every station on the network.<br />		* User activity can block the root loop for long periods, such as a LV dialog box and menu navigation. Whenever our application uses LV functions that go through the root loop, it will be blocked (hang) until the user activity completes. If a user leaves a menu open and then goes home for the weekend, it's possible to hang every station on the network.<br />
	** c. Opening untyped VI ref with PATH input type goes through root loop; opening untyped VI ref with STRING input type does not go through root loop.<br />		* Opening untyped VI ref with PATH input type goes through root loop; opening untyped VI ref with STRING input type does not go through root loop.<br />
	** d. Open TYPED VI reference always goes through root loop (regardless of path or string input).<br />		* Open TYPED VI reference always goes through root loop (regardless of path or string input).<br />
	** e. Invoking the Run method on a VI goes through the root loop (think of this as programmatically pressing the Run button).<br />		* Invoking the Run method on a VI goes through the root loop (think of this as programmatically pressing the Run button).<br />
	** f. Invoking the Abort method on a VI goes through the root loop (think of this as programmatically pressing the Abort button). When you close the last reference to a VI so it drops out of memory, it will also abort, but this does not involve the root loop.<br />		* Invoking the Abort method on a VI goes through the root loop (think of this as programmatically pressing the Abort button). When you close the last reference to a VI so it drops out of memory, it will also abort, but this does not involve the root loop.<br />

	# To avoid problems with the root loop:<br />		4. To avoid problems with the root loop:<br />
	** a. Do not use LV built-in dialogs; use dialog-mode subVI.<br />		* Do not use LV built-in dialogs; use dialog-mode subVI.<br />
	** b. Open TYPED VI reference as early as possible.<br />		* Open TYPED VI reference as early as possible.<br />
	** c. Use call by reference instead of using Run method whenever possible. Not possible if caller should not wait for other VI to finish (Wait until Done option only on Run method).<br />		* Use call by reference instead of using Run method whenever possible. Not possible if caller should not wait for other VI to finish (Wait until Done option only on Run method).<br />
	** d. To use call by reference for Vis with different, unknown connector panes, use Get/SetControlValue methods to set inputs & outputs instead of wiring to connector pane in Call by Ref; and force Vis to conform to "blank" connector pane (this can be set programmatically).<br />		* To use call by reference for Vis with different, unknown connector panes, use Get/SetControlValue methods to set inputs & outputs instead of wiring to connector pane in Call by Ref; and force Vis to conform to "blank" connector pane (this can be set programmatically).<br />
	** e. To keep VI Refs valid for as long as possible, we launch a looping VI that takes requests off a queue and opens ALL the VI refs for our application (both local and remote refs).<br />		* To keep VI Refs valid for as long as possible, we launch a looping VI that takes requests off a queue and opens ALL the VI refs for our application (both local and remote refs).<br />
	** f. We need to know if a VI that we have started running in the background (not waiting until done) has finished. We have the reentrant reference to the VI; but the property "VI state" does not		* We need to know if a VI that we have started running in the background (not waiting until done) has finished. We have the reentrant reference to the VI; but the property "VI state" does not distinguish between running and reserved. We considered closing this reentrant reference as the last thing in the running VI itself (which would abort it) so that we could know the VI was complete if the reference was invalid. However, if a VI (or one of its subVIs) closes its own reentrant reference, LV 6.1 will crash. So we had to set a Boolean control on the Vi's front panel to True as the first thing in the VI's code and to False as the last thing. The application can read this Boolean (must use GetControlValue method, not Value property) to find out if the VI is running.<br />
	distinguish between running and reserved. We considered closing this reentrant reference as the last thing in the running VI itself (which would abort it) so that we could know the VI was complete if the reference was invalid. However, if a VI (or one of its subVIs) closes its own reentrant reference, LV 6.1 will crash. So we had to set a Boolean control on the Vi's front panel to True as the first thing in the VI's code and to False as the last thing. The application can read this Boolean (must use GetControlValue method, not Value property) to find out if the VI is running.<br />		* Catch 22: VI Refs Fact (d) vs. Root Loop Facts (e & f). If we might need to abort a VI that we have started running in the background, we have to use the Run method to start it, so we can't avoid going through the root loop then. But we can close its (reentrant) reference instead of using the Abort method to avoid the root loop there.<br />
	** g. Catch 22: VI Refs Fact (d) vs. Root Loop Facts (e & f). If we might need to abort a VI that we have started running in the background, we have to use the Run method to start it, so we can't avoid going through the root loop then. But we can close its (reentrant) reference instead of using the Abort method to avoid the root loop there.<br />

	[b]Meg Kay[/b] and [b]Veda Murthy[/b] of Jova Solutions, Inc.<br />		[b]Meg Kay[/b] and [b]Veda Murthy[/b] of Jova Solutions, Inc.<br />
	June 26, 2002		June 26, 2002

← Older revision		Revision as of 23:07, 26 October 2007
Line 1:		Line 1:
	When launching LabView VIs using VI Server, the intrepid programmer may run across some stumbling blocks. Below is a collection of issues that Jova Solutions documented while implementing a method to allow users of a built LabView executable to have their own labview code run by the executable. This information was collected while working in LabView 6.1 and 7.0, and is valid for 7.1 as well, according to NI Developers. We welcome input from groups working in 8.0 or higher.<br />		When launching LabView VIs using VI Server, the intrepid programmer may run across some stumbling blocks. Below is a collection of issues that Jova Solutions documented while implementing a method to allow users of a built LabView executable to have their own labview code run by the executable. This information was collected while working in LabView 6.1 and 7.0, and is valid for 7.1 as well, according to NI Developers. We welcome input from groups working in 8.0 or higher.<br />

	1. Facts about App, VI, and Control References:<br />		# Facts about App, VI, and Control References:<br />
	a. You cannot test an Application Refnum using Not-A-Refnum; you must try using it, e.g. read the Name property and test the error returned. This is time-consuming (?).<br />		** a. You cannot test an Application Refnum using Not-A-Refnum; you must try using it, e.g. read the Name property and test the error returned. This is time-consuming (?).<br />
	b. Opening Application Ref with default empty string (local machine) uses ActiveX for VI Server functions (ActiveX must be enabled in Options -> VI Server: Configuration, Protocols). Opening Application Ref with any string input, including local machine name instead of default empty string uses TCPIP for VI Server functions (TCPIP must be enabled in Options -> VI Server: Configuration, Protocols). Using TCPIP VI Server functions is slower than using ActiveX; so always use empty string instead of local machine name.<br />		** b. Opening Application Ref with default empty string (local machine) uses ActiveX for VI Server functions (ActiveX must be enabled in Options -> VI Server: Configuration, Protocols). Opening Application Ref with any string input, including local machine name instead of default empty string uses TCPIP for VI Server functions (TCPIP must be enabled in Options -> VI Server: Configuration, Protocols). Using TCPIP VI Server functions is slower than using ActiveX; so always use empty string instead of local machine name.<br />
	c. Opening VI Refs - benchmarks (non-reentrant faster to open		** c. Opening VI Refs - benchmarks (non-reentrant faster to open
	than reentrant, untyped faster than typed, ...)<br />		than reentrant, untyped faster than typed, ...)<br />
	d. VI Reference will become invalid (disposed by LV) when call chain of VI that opened the reference finishes running. The VI that opened the reference might still be in memory and reserved by a different caller, but that doesn't keep original caller's references valid.<br />		** d. VI Reference will become invalid (disposed by LV) when call chain of VI that opened the reference finishes running. The VI that opened the reference might still be in memory and reserved by a different caller, but that doesn't keep original caller's references valid.<br />
	e. Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.<br />		** e. Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.<br />
	f. Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.<br />		** f. Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.<br />
	g. Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property.<br />		** g. Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property.<br />

	2. To avoid problems with references:<br />		# To avoid problems with references:<br />
	a. Test AppRef by reading application property, such as name. This is expensive.<br />		** a. Test AppRef by reading application property, such as name. This is expensive.<br />
	b. Always use empty string to open an AppRef to the local LV, instead of the local machine name.<br />		** b. Always use empty string to open an AppRef to the local LV, instead of the local machine name.<br />
	c. Open and manage VI refs in independent VI that stays running for the life of the application.<br />		** c. Open and manage VI refs in independent VI that stays running for the life of the application.<br />
	d. Preload VIs using PATH as early as possible and keep that initial reference open so VI stays in memory (non-reentrant because faster to open; won't be used to call VI), then any subsequent Open of untyped reentrant VI refs can use STRING name input.<br />		** d. Preload VIs using PATH as early as possible and keep that initial reference open so VI stays in memory (non-reentrant because faster to open; won't be used to call VI), then any subsequent Open of untyped reentrant VI refs can use STRING name input.<br />
	e. Use Get/SetControlValue instead of Value property for controls on reentrant VI.<br />		** e. Use Get/SetControlValue instead of Value property for controls on reentrant VI.<br />

	3. Facts about LV Execution: the [b]Root Loop[/b]<br />		# Facts about LV Execution: the [b]Root Loop[/b]<br />
	a. The LV execution system processes certain user interface activity in sequential order in "root loop."<br />		** a. The LV execution system processes certain user interface activity in sequential order in "root loop."<br />
	b. User activity can block the root loop for long periods, such as a LV dialog box and menu navigation. Whenever our application uses LV functions that go through the root loop, it will be blocked (hang) until the user activity completes. If a user leaves a menu open and then goes home for the weekend, it's possible to hang every station on the network.<br />		** b. User activity can block the root loop for long periods, such as a LV dialog box and menu navigation. Whenever our application uses LV functions that go through the root loop, it will be blocked (hang) until the user activity completes. If a user leaves a menu open and then goes home for the weekend, it's possible to hang every station on the network.<br />
	c. Opening untyped VI ref with PATH input type goes through root loop; opening untyped VI ref with STRING input type does not go through root loop.<br />		** c. Opening untyped VI ref with PATH input type goes through root loop; opening untyped VI ref with STRING input type does not go through root loop.<br />
	d. Open TYPED VI reference always goes through root loop (regardless of path or string input).<br />		** d. Open TYPED VI reference always goes through root loop (regardless of path or string input).<br />
	e. Invoking the Run method on a VI goes through the root loop (think of this as programmatically pressing the Run button).<br />		** e. Invoking the Run method on a VI goes through the root loop (think of this as programmatically pressing the Run button).<br />
	f. Invoking the Abort method on a VI goes through the root loop (think of this as programmatically pressing the Abort button). When you close the last reference to a VI so it drops out of memory, it will also abort, but this does not involve the root loop.<br />		** f. Invoking the Abort method on a VI goes through the root loop (think of this as programmatically pressing the Abort button). When you close the last reference to a VI so it drops out of memory, it will also abort, but this does not involve the root loop.<br />

	4. To avoid problems with the root loop:<br />		# To avoid problems with the root loop:<br />
	a. Do not use LV built-in dialogs; use dialog-mode subVI.<br />		** a. Do not use LV built-in dialogs; use dialog-mode subVI.<br />
	b. Open TYPED VI reference as early as possible.<br />		** b. Open TYPED VI reference as early as possible.<br />
	c. Use call by reference instead of using Run method whenever possible. Not possible if caller should not wait for other VI to finish (Wait until Done option only on Run method).<br />		** c. Use call by reference instead of using Run method whenever possible. Not possible if caller should not wait for other VI to finish (Wait until Done option only on Run method).<br />
	d. To use call by reference for Vis with different, unknown connector panes, use Get/SetControlValue methods to set inputs & outputs instead of wiring to connector pane in Call by Ref; and force Vis to conform to "blank" connector pane (this can be set programmatically).<br />		** d. To use call by reference for Vis with different, unknown connector panes, use Get/SetControlValue methods to set inputs & outputs instead of wiring to connector pane in Call by Ref; and force Vis to conform to "blank" connector pane (this can be set programmatically).<br />
	e. To keep VI Refs valid for as long as possible, we launch a looping VI that takes requests off a queue and opens ALL the VI refs for our application (both local and remote refs).<br />		** e. To keep VI Refs valid for as long as possible, we launch a looping VI that takes requests off a queue and opens ALL the VI refs for our application (both local and remote refs).<br />
	f. We need to know if a VI that we have started running in the background (not waiting until done) has finished. We have the reentrant reference to the VI; but the property "VI state" does not		** f. We need to know if a VI that we have started running in the background (not waiting until done) has finished. We have the reentrant reference to the VI; but the property "VI state" does not
	distinguish between running and reserved. We considered closing this reentrant reference as the last thing in the running VI itself (which would abort it) so that we could know the VI was complete if the reference was invalid. However, if a VI (or one of its subVIs) closes its own reentrant reference, LV 6.1 will crash. So we had to set a Boolean control on the Vi's front panel to True as the first thing in the VI's code and to False as the last thing. The application can read this Boolean (must use GetControlValue method, not Value property) to find out if the VI is running.<br />		distinguish between running and reserved. We considered closing this reentrant reference as the last thing in the running VI itself (which would abort it) so that we could know the VI was complete if the reference was invalid. However, if a VI (or one of its subVIs) closes its own reentrant reference, LV 6.1 will crash. So we had to set a Boolean control on the Vi's front panel to True as the first thing in the VI's code and to False as the last thing. The application can read this Boolean (must use GetControlValue method, not Value property) to find out if the VI is running.<br />
	g. Catch 22: VI Refs Fact (d) vs. Root Loop Facts (e & f). If we might need to abort a VI that we have started running in the background, we have to use the Run method to start it, so we can't avoid going through the root loop then. But we can close its (reentrant) reference instead of using the Abort method to avoid the root loop there.<br />		** g. Catch 22: VI Refs Fact (d) vs. Root Loop Facts (e & f). If we might need to abort a VI that we have started running in the background, we have to use the Run method to start it, so we can't avoid going through the root loop then. But we can close its (reentrant) reference instead of using the Abort method to avoid the root loop there.<br />

	Meg Kay and Veda Murthy of Jova Solutions, Inc.<br />		[b]Meg Kay[/b] and [b]Veda Murthy[/b] of Jova Solutions, Inc.<br />
	June 26, 2002		June 26, 2002

← Older revision		Revision as of 22:57, 26 October 2007
Line 1:		Line 1:
	When launching LabView VIs using VI Server, the intrepid programmer may run across some stumbling blocks. Below is a collection of issues that Jova Solutions documented while implementing a method to allow users of a built LabView executable to have their own labview code run by the executable. This information was collected while working in LabView 6.1 and 7.0, and is valid for 7.1 as well, according to NI Developers. We welcome input from groups working in 8.0 or higher.		When launching LabView VIs using VI Server, the intrepid programmer may run across some stumbling blocks. Below is a collection of issues that Jova Solutions documented while implementing a method to allow users of a built LabView executable to have their own labview code run by the executable. This information was collected while working in LabView 6.1 and 7.0, and is valid for 7.1 as well, according to NI Developers. We welcome input from groups working in 8.0 or higher.<br />

	1. Facts about App, VI, and Control References:		1. Facts about App, VI, and Control References:<br />
	a. You cannot test an Application Refnum using Not-A-Refnum; you must try using it, e.g. read the Name property and test the error returned. This is time-consuming (?).		a. You cannot test an Application Refnum using Not-A-Refnum; you must try using it, e.g. read the Name property and test the error returned. This is time-consuming (?).<br />
	b. Opening Application Ref with default empty string (local machine) uses ActiveX for VI Server functions (ActiveX must be enabled in Options -> VI Server: Configuration, Protocols). Opening Application Ref with any string input, including local machine name instead of default empty string uses TCPIP for VI Server functions (TCPIP must be enabled in Options -> VI Server: Configuration, Protocols). Using TCPIP VI Server functions is slower than using ActiveX; so always use empty string instead of local machine name.		b. Opening Application Ref with default empty string (local machine) uses ActiveX for VI Server functions (ActiveX must be enabled in Options -> VI Server: Configuration, Protocols). Opening Application Ref with any string input, including local machine name instead of default empty string uses TCPIP for VI Server functions (TCPIP must be enabled in Options -> VI Server: Configuration, Protocols). Using TCPIP VI Server functions is slower than using ActiveX; so always use empty string instead of local machine name.<br />
	c. Opening VI Refs - benchmarks (non-reentrant faster to open		c. Opening VI Refs - benchmarks (non-reentrant faster to open
	than reentrant, untyped faster than typed, ...)		than reentrant, untyped faster than typed, ...)<br />
	d. VI Reference will become invalid (disposed by LV) when call chain of VI that opened the reference finishes running. The VI that opened the reference might still be in memory and reserved by a different caller, but that doesn't keep original caller's references valid.		d. VI Reference will become invalid (disposed by LV) when call chain of VI that opened the reference finishes running. The VI that opened the reference might still be in memory and reserved by a different caller, but that doesn't keep original caller's references valid.<br />
	e. Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.		e. Closing a reentrant reference, or the only open non-reentrant reference, to a running VI will abort that VI because the VI's code drops out of memory. You cannot close a reference to a running VI that is being Called by Reference (acts like a reserved subVI), so the VI would have to be started by the Run method.<br />
	f. Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.		f. Control references only stay valid as long as the application reference, VI reference, panel reference, and parent control reference (if any) from which they came stay valid.<br />
	g. Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property.		g. Control references cannot be used with reentrant VIs, because, although a reentrant VI has multiple dataspaces (one for each instance), it only has one front panel with one set of controls. You can use Get/SetControlValue methods to access the front panel data, but you cannot use the Value property.<br />

	2. To avoid problems with references:		2. To avoid problems with references:<br />
	a. Test AppRef by reading application property, such as name. This is expensive.		a. Test AppRef by reading application property, such as name. This is expensive.<br />
	b. Always use empty string to open an AppRef to the local LV, instead of the local machine name.		b. Always use empty string to open an AppRef to the local LV, instead of the local machine name.<br />
	c. Open and manage VI refs in independent VI that stays running for the life of the application.		c. Open and manage VI refs in independent VI that stays running for the life of the application.<br />
	d. Preload VIs using PATH as early as possible and keep that initial reference open so VI stays in memory (non-reentrant because faster to open; won't be used to call VI), then any subsequent Open of untyped reentrant VI refs can use STRING name input.		d. Preload VIs using PATH as early as possible and keep that initial reference open so VI stays in memory (non-reentrant because faster to open; won't be used to call VI), then any subsequent Open of untyped reentrant VI refs can use STRING name input.<br />
	e. Use Get/SetControlValue instead of Value property for controls on reentrant VI.		e. Use Get/SetControlValue instead of Value property for controls on reentrant VI.<br />

	3. Facts about LV Execution: the [b]Root Loop[/b]		3. Facts about LV Execution: the [b]Root Loop[/b]<br />
	a. The LV execution system processes certain user interface activity in sequential order in "root loop."		a. The LV execution system processes certain user interface activity in sequential order in "root loop."<br />
	b. User activity can block the root loop for long periods, such as a LV dialog box and menu navigation. Whenever our application uses LV functions that go through the root loop, it will be blocked (hang) until the user activity completes. If a user leaves a menu open and then goes home for the weekend, it's possible to hang every station on the network.		b. User activity can block the root loop for long periods, such as a LV dialog box and menu navigation. Whenever our application uses LV functions that go through the root loop, it will be blocked (hang) until the user activity completes. If a user leaves a menu open and then goes home for the weekend, it's possible to hang every station on the network.<br />
	c. Opening untyped VI ref with PATH input type goes through root loop; opening untyped VI ref with STRING input type does not go through root loop.		c. Opening untyped VI ref with PATH input type goes through root loop; opening untyped VI ref with STRING input type does not go through root loop.<br />
	d. Open TYPED VI reference always goes through root loop (regardless of path or string input).		d. Open TYPED VI reference always goes through root loop (regardless of path or string input).<br />
	e. Invoking the Run method on a VI goes through the root loop (think of this as programmatically pressing the Run button).		e. Invoking the Run method on a VI goes through the root loop (think of this as programmatically pressing the Run button).<br />
	f. Invoking the Abort method on a VI goes through the root loop (think of this as programmatically pressing the Abort button). When you close the last reference to a VI so it drops out of memory, it will also abort, but this does not involve the root loop.		f. Invoking the Abort method on a VI goes through the root loop (think of this as programmatically pressing the Abort button). When you close the last reference to a VI so it drops out of memory, it will also abort, but this does not involve the root loop.<br />

	4. To avoid problems with the root loop:		4. To avoid problems with the root loop:<br />
	a. Do not use LV built-in dialogs; use dialog-mode subVI.		a. Do not use LV built-in dialogs; use dialog-mode subVI.<br />
	b. Open TYPED VI reference as early as possible.		b. Open TYPED VI reference as early as possible.<br />
	c. Use call by reference instead of using Run method whenever possible. Not possible if caller should not wait for other VI to finish (Wait until Done option only on Run method).		c. Use call by reference instead of using Run method whenever possible. Not possible if caller should not wait for other VI to finish (Wait until Done option only on Run method).<br />
	d. To use call by reference for Vis with different, unknown connector panes, use Get/SetControlValue methods to set inputs & outputs instead of wiring to connector pane in Call by Ref; and force Vis to conform to "blank" connector pane (this can be set programmatically).		d. To use call by reference for Vis with different, unknown connector panes, use Get/SetControlValue methods to set inputs & outputs instead of wiring to connector pane in Call by Ref; and force Vis to conform to "blank" connector pane (this can be set programmatically).<br />
	e. To keep VI Refs valid for as long as possible, we launch a looping VI that takes requests off a queue and opens ALL the VI refs for our application (both local and remote refs).		e. To keep VI Refs valid for as long as possible, we launch a looping VI that takes requests off a queue and opens ALL the VI refs for our application (both local and remote refs).<br />
	f. We need to know if a VI that we have started running in the background (not waiting until done) has finished. We have the reentrant reference to the VI; but the property "VI state" does not		f. We need to know if a VI that we have started running in the background (not waiting until done) has finished. We have the reentrant reference to the VI; but the property "VI state" does not
	distinguish between running and reserved. We considered closing this reentrant reference as the last thing in the running VI itself (which would abort it) so that we could know the VI was complete if the reference was invalid. However, if a VI (or one of its subVIs) closes its own reentrant reference, LV 6.1 will crash. So we had to set a Boolean control on the Vi's front panel to True as the first thing in the VI's code and to False as the last thing. The application can read this Boolean (must use GetControlValue method, not Value property) to find out if the VI is running.		distinguish between running and reserved. We considered closing this reentrant reference as the last thing in the running VI itself (which would abort it) so that we could know the VI was complete if the reference was invalid. However, if a VI (or one of its subVIs) closes its own reentrant reference, LV 6.1 will crash. So we had to set a Boolean control on the Vi's front panel to True as the first thing in the VI's code and to False as the last thing. The application can read this Boolean (must use GetControlValue method, not Value property) to find out if the VI is running.<br />
	g. Catch 22: VI Refs Fact (d) vs. Root Loop Facts (e & f). If we might need to abort a VI that we have started running in the background, we have to use the Run method to start it, so we can't avoid going through the root loop then. But we can close its (reentrant) reference instead of using the Abort method to avoid the root loop there.		g. Catch 22: VI Refs Fact (d) vs. Root Loop Facts (e & f). If we might need to abort a VI that we have started running in the background, we have to use the Run method to start it, so we can't avoid going through the root loop then. But we can close its (reentrant) reference instead of using the Abort method to avoid the root loop there.<br />

	Meg Kay and Veda Murthy of Jova Solutions, Inc.		Meg Kay and Veda Murthy of Jova Solutions, Inc.<br />
	June 26, 2002		June 26, 2002