|
|
| Line 1: |
Line 1: |
| {{ PrivateEvent | | {{ PrivateEvent |
| | example =BldApp.RemovePolyVIsandTypedefs=FALSE
| | | description =Triggered when the user makes LabVIEW the active application |
| | datatype =b
| |
| | description =Setting this to <code>FALSE</code> stops the LabVIEW Application Builder from aggressively removing polymorphic VIs and typedefs that it thinks are not required | |
| | permitted_values =TRUE or FALSE | | | permitted_values =TRUE or FALSE |
| | default =TRUE | | | minLVVersion = 8.2 |
| | LV1 = 7 | | | maxLVVersion = |
| | LV2 =
| |
| | LV3 =
| |
| | LV4 =
| |
| | LV5 =
| |
| | LV6 =
| |
| | OS1 =w | | | OS1 =w |
| | OS2 =m | | | OS2 = |
| | OS3 =l | | | OS3 = |
| | OS4 = | | | OS4 = |
| | notes =By default, the LabVIEW 7.x Application Builder does not include type definitions and unused instances of polymorphic VIs into executable in order to decrease size of application. This setting can be changed in the LabVIEW 7.1 applciation Builder in the Application Settings page. | | | NowPublic =No |
| If a VI in your build calls an external VI that uses a type definition in order to pass parameters, and the AppBuilder is unaware of this external VI, it will end in tears.
| |
| Also there is one other issue which makes this setting very important. In LabVIEW 7.x, by disconnecting typedefs from controls they did loose their default data and return to LabVIEWs default default data. This could be a major problem if you used strict typedefed clusters on front panels to provide certain default data when unwired and those default data did not match LabVIEWs default default data. This has been mostly fixed in newer LabVIEW versions from 8.0 on.
| |
| }} | | }} |
Revision as of 08:43, 17 January 2009
Application Activation
Description: Triggered when the user makes LabVIEW the active application
Minimal LabVIEW Version: 8.2
Class: {{{class}}}
Became Public?: No
OS's Supported:
Notes: {{{Notes}}}
