<<< Back to Main Page
OpenG.org July 2002 Edition
About The OpenG Application Builder
Installing the OpenG Application Builder Libraries
Using the OpenG Application Builder
From Windows Explorer
From a batch file
OpenG Application Builder Settings
Opening a VI in the LabVIEW Run-Time Environment
From the LabVIEW pull-down menu
From Windows Explorer
Wrapper VIs - How the OpenG Application Builder works
Intercepting The Call Chain
The OpenG Application Builder is an add-on package, which augments the features of the LabVIEW Application Builder, which must be installed on the target system in order to install/use the OpenG Application Builder. The LabVIEW Application Builder is a tool that allows one to build stand-alone run-time applications from LabVIEW VIs.
The OpenG Application Builder overcomes a major limitation of the LabVIEW Application Builder by adding a programmatic interface for building applications. However, it also adds some the other useful features, which include:
- Building an application by double-clicking on a .bld file from Windows explorer
- Icons for .bld files
- Right-Clicking .bld file to launch custom build settings dialog
- Optional segregation of OpenG VIs into an external library with their diagrams and front panels left intact and addition of LGPL text file, thus achieving LGPL compliance
- Windows date bug fix
- Command line interface for batch files
- Open a VI in the LabVIEW Run-Time environment, for testing an application before building an .exe.
The OpenG Application Builder requires the LabVIEW Application Builder during both installation and use. The LabVIEW Application builder is part of the default installation for the LabVIEW Professional Development System configuration but may be purchased and installed separately.
Complete the following steps to install the Application Builder.
Note Some virus detection programs interfere with the installer program. Check the distribution media for viruses before you begin installation. Then, turn off the automatic virus checker and run the installer. After installation, check your hard disk for viruses again and turn on the virus checker.
1. Unzip the Installation files to a temporary directory
2. Open "OGAB_Install.llb" from the Explorer using the LabVIEW instance in which you wish to install the OpenG Application Builder.
3. Select the "Install" button
4. Read the LGPL and agree to its terms and conditions.
Launch LabVIEW after you install the Application Builder and choose Tools"OpenG Application Builder"Build Application. This will launch the OpenG Application Builder.
Applications may be built from a .bld file programmatically by calling "OGAB Builder.vi", which is located at .\project\OGAB\OGAB.llb\OGAB Builder.vi. Of course, the call can also be made from another application using the ActiveX VI Server.
An application may be built from a .bld file by double-clicking on it or by selecting the "Build Application" right-click option.
An application may be built from a batch file or the command line. Issuing the command
wscript.exe "<labview dir>\project\OGAB\rsc\openbld.vbs" "<bld file path>"
will launch the application builder in a separate process and return immediately. If you want to wait until the build is finished, use the cscript.exe script host instead of wscript.exe
Each build file may have custom settings. These are stored in an .ini file located in the same directory as the .bld file. If a .bld file does not have a custom settings file, the settings in the Default Settings are used. The custom settings .ini file has the same name as the .bld file, but has an .ini file suffix appended to it. For example the file Application.bld would have a custom settings file named Application.bld.ini. The OpenG Application Builder creates this file when the custom settings of a .bld file are edited.
Application Type >> Traditional
A Traditional application is one that does not use any OpenG VIs and therefore does not require any special treatment.
Application Type >> OpenG
An OpenG application is one that uses OpenG VIs, which will be segregated into an external LLB with their diagrams and panels left intact. Non-OpenG VIs will be put in the internal LLB with their panels and diagrams optionally left intact (as determined by the Non-OpenG VI Settings Option). A copy of the LGPL license will be automatically placed in the destination location.
Default Application Icon
If OpenG is selected the OpenG Application Icon will be used instead of the default LabVIEW application icon when a custom icon is not selected in the .bld file.
If a .bld file does not have a custom settings file, the settings in the Default Settings are used.
Open this dialog when NI App Builder is launched
This option will cause the OpenG Application Builder Settings dialog to open automatically whenever the OpenG Application Builder is launch.
Warn me before building when OpenG VIs are included in Traditional App
This option will cause a warning dialog to be displayed before building a Traditional Application Type if it includes OpenG VIs and therefore may not comply with the LGPL.
Enable Date Bug Fix
There is a bug in the LabVIEW Application Builder that can be corrected by enabling this option.
From the VI to be opened in the Run-Time Environement, choose Tools>>OpenG Application Builder>>Open this VI in Run-Time. Make sure to save the VI before opening it in the Run-Time environement. Unsaved changes will not be reflected in VI once it is opened in Run-Time.
Right-Click on a VI and select Open in Run-Time.
A Wrapper VI is one which has the same inputs, outputs, and connector pane as another VI which it calls as a subVI. This subVI is referred to as the Wrapped VI. If another VI (henceforth referred to as the Caller VI) is a caller of the Wrapped VI, the Caller VI can be made to call the Wrapper VI instead. This is accomplished by (1) loading the Wrapper VI and the Wrapped VI into memory, then (2) saving the Wrapped VI with a new name (usually by prepending a common prefix), and then (3) saving the Wrapper VI with the original name of the Wrapped VI. When the Caller VI is subsequently loaded into memory, it becomes linked to the Wrapper VI instead of the Wrapped VI, which it was originally linked to. *Note that the Caller VI must not be in memory while the Wrapper VI and Wrapped VI are being renamed.
Because the Wrapped VI's input data flows from the Caller VI into the Wrapper VI and then into the Wrapped VI, the input data may be modified within the Wrapper VI prior to calling the Wrapped VI. Likewise the Wrapped VI's output data may be modified prior to passing it up to the Caller VI. Additionally within the Wrapper VI, we may do just about anything we wish. For example we may decide to step over the Wrapped VI and not even call it, or call a different VI altogether. We may decide to call additional VIs before and/or after calling the Wrapped VI. One use case would be for logging the VI's execution and/or data. For example; within the OpenG Application Builder, when building an application programmatically, user dialogs are suppressed. This allows the build process to not require any user interaction. If you wish to modify the functionality of the OpenG Application Builder, you should modify the Wrapper VIs, which are located within .\project\OGAB\OGAB_Wrappers.llb.