Application instance - Revision history

Q at 01:44, 22 March 2024

2024-03-22T01:44:35Z

← Older revision		Revision as of 01:44, 22 March 2024
Line 4:		Line 4:
	LabVIEW allows multiple application instances to run simultaneously, each isolated from the others. This capability is useful in situations where you might need to run multiple versions of an application or multiple applications that must not share data directly, ensuring that the execution of one instance does not interfere with another.		LabVIEW allows multiple application instances to run simultaneously, each isolated from the others. This capability is useful in situations where you might need to run multiple versions of an application or multiple applications that must not share data directly, ensuring that the execution of one instance does not interfere with another.

	Application instances are especially relevant in the context of LabVIEW projects that are deployed as standalone applications ~~or shared libraries (DLLs)~~. Each deployed application runs in its own application instance, separate from the LabVIEW development environment and any other running applications. This separation is critical for ensuring the reliability and stability of deployed applications, as it prevents conflicts between different running instances of LabVIEW code.		Application instances are especially relevant in the context of LabVIEW projects that are deployed as standalone applications. Each deployed application runs in its own application instance, separate from the LabVIEW development environment and any other running applications. This separation is critical for ensuring the reliability and stability of deployed applications, as it prevents conflicts between different running instances of LabVIEW code.

	Additionally, LabVIEW’s ability to manage multiple application instances is useful for modular programming, testing, and deployment scenarios, allowing developers to build complex, scalable, and maintainable systems.		Additionally, LabVIEW’s ability to manage multiple application instances is useful for modular programming, testing, and deployment scenarios, allowing developers to build complex, scalable, and maintainable systems.

Q: Formated and edited page, added more details

2024-03-22T01:41:50Z

Formated and edited page, added more details

@@ Line 1: / Line 1: @@
-The term "application instance" is used in all public documentation, but in the LabVIEW C++ code, those same things are called "contexts". Because R&amp;D folks occasionally post to customers without tech writers reading over our shoulders, we slip up and use the other term. So you should generally regard those terms as interchangeable, but know that "application instance" is preferred for a long list of (very good) reasons.
+{{TOCright}}
-An app instance is very nearly an isolated LabVIEW.exe. The VIs in one app instance cannot interact with the VIs in another context unless they do the same things that would be required to talk to a VI that was loaded on a separate machine entirely. So whatever you would do to talk to a network VI is the stuff you generally have to do to talk to a VI in another app instance.
+LabVIEW allows multiple application instances to run simultaneously, each isolated from the others. This capability is useful in situations where you might need to run multiple versions of an application or multiple applications that must not share data directly, ensuring that the execution of one instance does not interfere with another.
-Application Refnums are the references to an app instance. Prior to 8.0, you would open an app reference to an entire LabVIEW execution system. Now you open an app reference to one app instance within the execution system.
+Application instances are especially relevant in the context of LabVIEW projects that are deployed as standalone applications or shared libraries (DLLs). Each deployed application runs in its own application instance, separate from the LabVIEW development environment and any other running applications. This separation is critical for ensuring the reliability and stability of deployed applications, as it prevents conflicts between different running instances of LabVIEW code.
-All LabVIEW files -- VIs, libraries, projects -- load into an app instance. The same file may be loaded into multiple app instances simultaneously. Editing one of the "reflections" (a term that R&amp;D uses which is distinct from "clones" of a VI, which has to do with reentrancy) does not change the other reflections of that file until you synchronize the app instances (either by pressing that green arrow button that appears on the VI next to the Run arrow OR by saving the file).
+Additionally, LabVIEW’s ability to manage multiple application instances is useful for modular programming, testing, and deployment scenarios, allowing developers to build complex, scalable, and maintainable systems.
-Projects are loaded into an app instance, but they also manage a set of app instances. The "My Computer" instance is the one that the project is actually loaded into. If you add any targets to a project -- an FPGA target, RT target, etc -- those are other app instances. *All* of the app instances that a project creates, including the "My Computer" instance, are life-time managed by the project, meaning that when you close the project, you close the app instance, which closes out all the VIs and Libraries loaded into those app instances.
+== Application Instance vs Contexts ==
-Any given app instance may be owned by zero or one projects, but not more.
+== Isolation of Application Instances ==
-LabVIEW has multiple private app instances, including the "NI.LV.Dialog" app instance which is where VIs from the Tools menu run. These private contexts allow tools written with VIs to run without interfering with the user app instances, so there is never a chance of one of those VIs cross linking with user VIs or keeping a user VI from being able to load because a VI of that name is already in memory. Various parts of LabVIEW will create temporary app instances -- for example, AppBuilder creates a temporary app instance which it loads all the source VIs into so that it can rename them, strip diagrams, etc, without touching the user's original source files.
+All LabVIEW files -- VIs, libraries, projects -- load into an application instance. The same file may be loaded into multiple app instances simultaneously. Editing one of the "reflections" (a term that R&amp;D uses which is distinct from "clones" of a VI, which has to do with reentrancy) does not change the other reflections of that file until you synchronize the application instances (either by pressing the green arrow button that appears on the VI next to the Run arrow OR by saving the file).
-Users can create their own temporary app instances. I believe the Open Application Refnum primitive can be used for this by providing a unique port number to the primitive. There are other methods as well. This is an area of LabVIEW where my knowledge is pretty weak and others may be able to fill in more details.
+[[LabVIEW Class]]es and [[LabVIEW Project Library|LabVIEW Project Libraries]] can be loaded in multiple instances at the same time but will become uneditable. This will become apparent in [[Project Explorer]] due to the class or library becoming locked.
-[[Category:Application_control]]
+Projects are loaded into an application instance, but they also manage a set of application instances. The "My Computer" instance is the one that the project is loaded into. If you add any targets to a project, (an FPGA target, RT target, etc.), those are other application instances. *All* of the app instances that a project creates, including the "My Computer" instance, are lifetime managed by the project, meaning that when you close the project, you close the application instance, which closes out all the VIs and Libraries loaded into those application instances.

Michael_Aivaliotis at 19:49, 3 February 2009

2009-02-03T19:49:56Z

← Older revision		Revision as of 19:49, 3 February 2009
Line 13:		Line 13:
	LabVIEW has multiple private app instances, including the "NI.LV.Dialog" app instance which is where VIs from the Tools menu run. These private contexts allow tools written with VIs to run without interfering with the user app instances, so there is never a chance of one of those VIs cross linking with user VIs or keeping a user VI from being able to load because a VI of that name is already in memory. Various parts of LabVIEW will create temporary app instances -- for example, AppBuilder creates a temporary app instance which it loads all the source VIs into so that it can rename them, strip diagrams, etc, without touching the user's original source files.		LabVIEW has multiple private app instances, including the "NI.LV.Dialog" app instance which is where VIs from the Tools menu run. These private contexts allow tools written with VIs to run without interfering with the user app instances, so there is never a chance of one of those VIs cross linking with user VIs or keeping a user VI from being able to load because a VI of that name is already in memory. Various parts of LabVIEW will create temporary app instances -- for example, AppBuilder creates a temporary app instance which it loads all the source VIs into so that it can rename them, strip diagrams, etc, without touching the user's original source files.

	Users can create their own temporary app instances. I believe the Open Application Refnum primitive can be used for this by providing a unique port number to the primitive. There are other methods as well. This is an area of LabVIEW where my knowledge is pretty weak and others may be able to fill in more details. ~~<br> <!-- Tidy found serious XHTML errors --> <!-- Tidy found serious XHTML errors -->~~		Users can create their own temporary app instances. I believe the Open Application Refnum primitive can be used for this by providing a unique port number to the primitive. There are other methods as well. This is an area of LabVIEW where my knowledge is pretty weak and others may be able to fill in more details.

	[[Category:Application_control]]		[[Category:Application_control]]

Michael_Aivaliotis at 19:49, 3 February 2009

2009-02-03T19:49:28Z

← Older revision		Revision as of 19:49, 3 February 2009
Line 15:		Line 15:
	Users can create their own temporary app instances. I believe the Open Application Refnum primitive can be used for this by providing a unique port number to the primitive. There are other methods as well. This is an area of LabVIEW where my knowledge is pretty weak and others may be able to fill in more details. <br> <!-- Tidy found serious XHTML errors --> <!-- Tidy found serious XHTML errors -->		Users can create their own temporary app instances. I believe the Open Application Refnum primitive can be used for this by providing a unique port number to the primitive. There are other methods as well. This is an area of LabVIEW where my knowledge is pretty weak and others may be able to fill in more details. <br> <!-- Tidy found serious XHTML errors --> <!-- Tidy found serious XHTML errors -->

	[[Category:Application_control]]~~ <!-- Tidy found serious XHTML errors -->~~		[[Category:Application_control]]
	~~<!-- Tidy found serious XHTML errors -->~~

Tcplomp at 10:46, 3 February 2009

2009-02-03T10:46:24Z

← Older revision		Revision as of 10:46, 3 February 2009
Line 13:		Line 13:
	LabVIEW has multiple private app instances, including the "NI.LV.Dialog" app instance which is where VIs from the Tools menu run. These private contexts allow tools written with VIs to run without interfering with the user app instances, so there is never a chance of one of those VIs cross linking with user VIs or keeping a user VI from being able to load because a VI of that name is already in memory. Various parts of LabVIEW will create temporary app instances -- for example, AppBuilder creates a temporary app instance which it loads all the source VIs into so that it can rename them, strip diagrams, etc, without touching the user's original source files.		LabVIEW has multiple private app instances, including the "NI.LV.Dialog" app instance which is where VIs from the Tools menu run. These private contexts allow tools written with VIs to run without interfering with the user app instances, so there is never a chance of one of those VIs cross linking with user VIs or keeping a user VI from being able to load because a VI of that name is already in memory. Various parts of LabVIEW will create temporary app instances -- for example, AppBuilder creates a temporary app instance which it loads all the source VIs into so that it can rename them, strip diagrams, etc, without touching the user's original source files.

	Users can create their own temporary app instances. I believe the Open Application Refnum primitive can be used for this by providing a unique port number to the primitive. There are other methods as well. This is an area of LabVIEW where my knowledge is pretty weak and others may be able to fill in more details. <br> <!-- Tidy found serious XHTML errors -->		Users can create their own temporary app instances. I believe the Open Application Refnum primitive can be used for this by providing a unique port number to the primitive. There are other methods as well. This is an area of LabVIEW where my knowledge is pretty weak and others may be able to fill in more details. <br> <!-- Tidy found serious XHTML errors --> <!-- Tidy found serious XHTML errors -->

			[[Category:Application_control]] <!-- Tidy found serious XHTML errors -->
	<!-- Tidy found serious XHTML errors -->		<!-- Tidy found serious XHTML errors -->

Michael_Aivaliotis: Recreated this page from a previous failed attempt by TiT. Not sure what happened to the previous page but here it is again.

2009-02-02T20:09:54Z

Recreated this page from a previous failed attempt by TiT. Not sure what happened to the previous page but here it is again.

New page

The term "application instance" is used in all public documentation, but in the LabVIEW C++ code, those same things are called "contexts". Because R&D folks occasionally post to customers without tech writers reading over our shoulders, we slip up and use the other term. So you should generally regard those terms as interchangeable, but know that "application instance" is preferred for a long list of (very good) reasons.

An app instance is very nearly an isolated LabVIEW.exe. The VIs in one app instance cannot interact with the VIs in another context unless they do the same things that would be required to talk to a VI that was loaded on a separate machine entirely. So whatever you would do to talk to a network VI is the stuff you generally have to do to talk to a VI in another app instance.

Application Refnums are the references to an app instance. Prior to 8.0, you would open an app reference to an entire LabVIEW execution system. Now you open an app reference to one app instance within the execution system.

All LabVIEW files -- VIs, libraries, projects -- load into an app instance. The same file may be loaded into multiple app instances simultaneously. Editing one of the "reflections" (a term that R&D uses which is distinct from "clones" of a VI, which has to do with reentrancy) does not change the other reflections of that file until you synchronize the app instances (either by pressing that green arrow button that appears on the VI next to the Run arrow OR by saving the file).

Projects are loaded into an app instance, but they also manage a set of app instances. The "My Computer" instance is the one that the project is actually loaded into. If you add any targets to a project -- an FPGA target, RT target, etc -- those are other app instances. *All* of the app instances that a project creates, including the "My Computer" instance, are life-time managed by the project, meaning that when you close the project, you close the app instance, which closes out all the VIs and Libraries loaded into those app instances.

Any given app instance may be owned by zero or one projects, but not more.

LabVIEW has multiple private app instances, including the "NI.LV.Dialog" app instance which is where VIs from the Tools menu run. These private contexts allow tools written with VIs to run without interfering with the user app instances, so there is never a chance of one of those VIs cross linking with user VIs or keeping a user VI from being able to load because a VI of that name is already in memory. Various parts of LabVIEW will create temporary app instances -- for example, AppBuilder creates a temporary app instance which it loads all the source VIs into so that it can rename them, strip diagrams, etc, without touching the user's original source files.

Users can create their own temporary app instances. I believe the Open Application Refnum primitive can be used for this by providing a unique port number to the primitive. There are other methods as well. This is an area of LabVIEW where my knowledge is pretty weak and others may be able to fill in more details. <br>