Target Settings for Executables
When you set the Target Type to Executable and select Build»Target Settings, the Target Settings dialog box has the following options:
 |
Note Refer to the Persistence of LabWindows/CVI Dialog Box Options topic for more information about where dialog box options are saved and what they affect. |
- Configuration—Specifies the configuration(s) to which the settings apply. The following configurations are listed by default:
- Debug—Settings apply to the default 32-bit debug configuration.
- Release—Settings apply to the default 32-bit release configuration.
- Debug64—Settings apply to the default 64-bit debug configuration.
- Release64—Settings apply to the default 64-bit release configuration.
- All Configurations—Changed settings apply to all configurations.
Note - Any custom configurations you create are also listed.
- If you access the Target Settings dialog box from the Add Configuration or Edit Configuration dialog boxes, LabWindows/CVI dims the Configuration option. LabWindows/CVI applies the changes you make in this dialog box to the configuration specified in the Add Configuration or Edit Configuration dialog box.
- Application file—The names of the executable file of your program. You can use the Browse button to select an existing filename.
- Application title—A descriptive title for your program.
- Application icon file—A file that contains a descriptive graphical icon for your program. You can use the Browse button to select an existing icon file.
- Icon—The graphical representation of the Application icon file. You can double-click Icon to browse for an icon file on disk. The sample program samples\apps\iconedit\iconedit.exe ships with LabWindows/CVI so that you can create your own icon files.
- Run-time support—The run-time support for your executable. If you select the Instrument driver only item, your project does not link to the entire set of LabWindows/CVI libraries but instead links to a smaller set of functions.
Executables you create with the Full runtime item selected use the LabWindows/CVI Runtime DLL, cvirte.dll. - Runtime binding—Binds the executable to the specified LabWindows/CVI Runtime.
Note Refer to the Runtime Usage topic for more information about how this option affects the behavior of bound executables and DLLs. - Shared—Binds the executable to the default, shared LabWindows/CVI Runtime. This option is appropriate for most applications.
- <version> side-by-side for entire application—Binds the executable to the version of the LabWindows/CVI Side-by-Side Runtime indicated by <version>. Any DLLs in the application bound to the shared runtime use the version of the LabWindows/CVI Side-by-Side Runtime to which the executable is bound. DLLs bound to a specific LabWindows/CVI Side-by-Side Runtime use the version of the side-by-side runtime to which they are bound. Use this option to minimize the possibility of loading multiple versions of the LabWindows/CVI Runtime into memory. This option is appropriate for most applications that need to be isolated from upgrades or downgrades to the LabWindows/CVI Runtime.
Note When you use this option and the application calls a DLL bound to the LabWindows/CVI Shared Runtime, ensure that the version of the side-by-side runtime to which you bind the executable is later than or equal to the version of LabWindows/CVI used to build the DLL; otherwise, the LabWindows/CVI Runtime will not be able to resolve entry points in the DLL. - <version> side-by-side for executable only—Binds the executable to the version of the LabWindows/CVI Side-by-Side Runtime indicated by <version>. Any DLLs in the application bound to the shared runtime use the LabWindows/CVI Shared Runtime. Use this option to minimize the likelihood of a DLL not being able to load because the runtime of the executable is older than the runtime the DLL was built against.
- Generate help from source—After you insert and edit template comment tags, you can export the function documentation by selecting one of the following items:
- None (default)—Does not generate documentation from the code comments.
- XML—Generates a .xml file from the code comments and places the file in the same folder as the LabWindows/CVI project. You then can process the .xml file using an XML parser.
- HTML—Generates .html files from the code comments and places the files in the same folder as the LabWindows/CVI project.
- HTML & XML—Generates both .xml and .html files from the code comments and places the files in the same folder as the LabWindows/CVI project.
- Embed manifest file—Embeds the manifest (.manifest) file you specify into the executable. Manifest files are XML files that contain information about the dependencies, security, assembly, and so on of your application. Refer to the KnowledgeBase on ni.com for more information about application manifests.
- Embed project .UIRs—Embeds .uir files into the executable. Enabling this option allows you to ship only the executable, instead of including the .uir files also. Make sure that you include all .uir files loaded through LoadPanel or LoadPanelEx in your project if you want to ship only the executable file. If you pass an absolute filename to LoadPanel or LoadPanelEx, the function will always look on disk for the .uir file. If you pass a simple filename, LoadPanel or LoadPanelEx will look first for an embedded .uir.
- Generate map file—Creates a memory map for the executable. This map lists the address of every function and variable and the name of the function or variable. This option is useful if your program crashes and provides an address where the failure occurred. You can view the map file to check which function or variable the crash occurred in.
LabWindows/CVI generates the map file in the cvibuild.projectname/configname directory under the main project directory. The file is named map_projectname_Configuration.txt. - Create console application—If you disable this option, LabWindows/CVI creates your executable as a Windows GUI application. If you enable this option, LabWindows/CVI creates your executable as a console application. Console applications create a Windows console window (Command Prompt window). Create a console application if you want to redirect the standard input or output of your program.
By default, the Windows console window moves to the foreground each time data is written to it. You can disable this behavior with the SetStdioWindowOptions function.
Projects with the Run-time support option set to Instrument driver only do not support the Windows console window. Functions such as FmtOut, ScanIn, printf, and scanf do not display output to the console window for Instrument driver only projects. - Embed timestamp—Adds the time at which you built the project to the .exe file you create.
- Register ActiveX server after build—LabWindows/CVI registers the target each time that it builds the target. By default, this option is enabled for a new ActiveX server project. This option appears only for ActiveX server projects.
Note When you build ActiveX servers, the ActiveX servers are registered in your user profile. This registration is not visible to other users on your system. When you register these servers outside the LabWindows/CVI environment, they are always registered for all users; this option requires administrator privilege. - Version Info—Opens the Version Info dialog box.
- Signing Info—Opens the Signing Information dialog box.
- LoadExternalModule Options—The following options assist you in loading external modules.
- Enable LoadExternalModule—Select this option if your project uses LoadExternalModule. If your project does not use LoadExternalModule, disable this option to reduce the size of your executable. If you disable the option but still use LoadExternalModule, LabWindows/CVI prompts you to enable full support. You must rebuild your project before the changes take effect.
- Add Files to Executable—Select additional module files you want to link into the Application file. These are modules that your project files do not directly reference but that are referenced by modules you load at run time by calling LoadExternalModule.
If you force a Windows SDK import library into your project, your executable might not start up successfully. The Windows SDK import libraries contain functions that are not present on all versions of Windows. If the DLL on your system does not export all the functions in the import library, your executable will fail at startup. Instead of forcing an import library into your executable, you can force only the functions you need into the executable. To force specific functions into your executable, create a table of function pointers and add the functions to the table. For example, to force references to CreateWindow and GetFreeDiskSpace, you can add the following code to a source file in your project.
void* ReferenceFunctionsTable[] = {
CreateWindow,
GetDiskFreeSpace,
}
- OK—Accepts the current inputs and closes the dialog box.
- Cancel—Cancels the operation and closes the dialog box.