Run-Time Engine Limitations - Revision history

Michael_Aivaliotis at 10:18, 8 October 2007

2007-10-08T10:18:51Z

← Older revision		Revision as of 10:18, 8 October 2007
Line 1:		Line 1:

	== Make Current Values Default ==		== Make Current Values Default ==

Line 17:		Line 16:
	Should the Application Builder issue a warning about the use of this method?		Should the Application Builder issue a warning about the use of this method?
	Well in principle, an application can open an application and VI references to LabVIEW Development and change the VI default values. There is no problem since the method is executed in LabVIEW Development even if it is invoked from a built application. At built-time it is not always possible to track the origin of the VI reference so giving a warning is not always justified. A warning (even a broken VI if the input is made required) could be issued when the VI Reference input is not wired (defaults to self VI) in which case the method doesn't work at all, Development or Application		Well in principle, an application can open an application and VI references to LabVIEW Development and change the VI default values. There is no problem since the method is executed in LabVIEW Development even if it is invoked from a built application. At built-time it is not always possible to track the origin of the VI reference so giving a warning is not always justified. A warning (even a broken VI if the input is made required) could be issued when the VI Reference input is not wired (defaults to self VI) in which case the method doesn't work at all, Development or Application

			[[category:building executables]]

MichaelAivaliotis at 22:31, 17 March 2007

2007-03-17T22:31:38Z

← Older revision		Revision as of 22:31, 17 March 2007
Line 1:		Line 1:

			== Make Current Values Default ==


	The VI method "Make Current Values Default" requires that the VI is in edit mode to work. That means that the method has to be invoked from another running VI. The VI must also be saved after the modifications in order to make them permanent. The VI is also probably recompiled. The technique can be used to store the last user settings from one run to another.		The VI method "Make Current Values Default" requires that the VI is in edit mode to work. That means that the method has to be invoked from another running VI. The VI must also be saved after the modifications in order to make them permanent. The VI is also probably recompiled. The technique can be used to store the last user settings from one run to another.

MichaelAivaliotis: New page: The VI method "Make Current Values Default" requires that the VI is in edit mode to work. That means that the method has to be invoked from another running VI. The VI must also be saved af...

2007-03-17T22:31:13Z

New page: The VI method "Make Current Values Default" requires that the VI is in edit mode to work. That means that the method has to be invoked from another running VI. The VI must also be saved af...

New page

The VI method "Make Current Values Default" requires that the VI is in edit mode to work. That means that the method has to be invoked from another running VI. The VI must also be saved after the modifications in order to make them permanent. The VI is also probably recompiled. The technique can be used to store the last user settings from one run to another.

In C, the operation is equivalent to modifying an initialized declaration statement in the source code such as:

[code]long int PI = 3ul // for users in Alabama[/code]

Then the source file has to be saved, compiled and application rebuilt.

Each of these three operations (edit, compile, save) can only be done by the LabVIEW Development environment. There is no need, in a built application to modify, recompile and save VIs so the method is not made available.

To restore users settings after a run, it is recommended to use a file. At initialization, the file is read and controls are populated with file data. At program exit, control values are read and saved to file. The File Config utilities from [[OpenG]] Toolkit provides VIs with this functionality.

Should the Application Builder issue a warning about the use of this method?
Well in principle, an application can open an application and VI references to LabVIEW Development and change the VI default values. There is no problem since the method is executed in LabVIEW Development even if it is invoked from a built application. At built-time it is not always possible to track the origin of the VI reference so giving a warning is not always justified. A warning (even a broken VI if the input is made required) could be issued when the VI Reference input is not wired (defaults to self VI) in which case the method doesn't work at all, Development or Application