LabVIEW Wiki - User contributions [en]

LabVIEW configuration file/Getting Started Window

2024-01-02T18:36:14Z

Playerm1: GSW_RSSCheckEnabled, corrected "FALS" to "FALSE"

This is a list of LabVIEW ini File settings relating to the Getting Started Window.

{{TOCright}}

{{ labviewconfigurationkey
| keyname =GSW_filter
| example =GSW_filter=0
| datatype =i
| description =Filter on files to show in recent list.
| permitted_values ={0 = All, 1 = Recent Projects, 2 = Recent VIs, 3 = Other Recent Files}
| default = 0
| LV1 = 2012+
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname =GSW_Pinned_Files
| example =GSW_Pinned_Files="C:\Projects\Project 1\Project 1.lvproj;C:\Projects\Project 2\VI2.vi"
| datatype =s
| description =The paths of recently opened files.
| permitted_values =Paths, semi-colon separated.
| default = <blank> or no key
| LV1 = 2012+
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname =GSW_Pinned_Templates
| example =GSW_Pinned_Templates="C:\Program Files (x86)\National Instruments\LabVIEW 2019\ProjectTemplates\Source\Delacor\Delacor QMH"
| datatype =s
| description =The paths of recently opened templates.
| permitted_values =Paths, semi-colon separated.
| default = <blank> or no key
| LV1 = 2012+
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname =GSW_Pinned_Templates_names
| example =GSW_Pinned_Templates_names="Delacor QMH"
| datatype =s
| description =The names of recently opened Project Templates.
| permitted_values =Strinngs, semi-colon separated.
| default = <blank> or no key
| LV1 = 2012+
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname =GSW_RSSCheckEnabled
| example =GSW_RSSCheckEnabled=FALSE
| datatype =b
| description =Stop LabVIEW from checking ni.com for updates to the "Latest from ni.com", "Online Support" and "Help" lists.
| permitted_values =TRUE or FALSE
| default =TRUE
| LV1 = 2009
| LV2 = 2010
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname =MaxGSWRecentProjects
| example =MaxGSWRecentProjects=5
| datatype =i
| description =Set the number of recently opened projects in the "Open" list of the Getting Started Window
| permitted_values =0...
| default =2
| LV1 = 2009
| LV2 = 2010
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname =NI_GSWPosition
| example =NI_GSWPosition="505,196,1416,844"
| datatype =s
| description =List of position points "Top, Left, Bottom, Right"
| permitted_values ="Number,Number,Number,Number"
| default =2
| LV1 = 2012+
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname =RecentFiles.pathList
| example =RecentFiles.projectPathList="C:\Projects\Project 1\VI1.vi;C:\Projects\Project 2\VI2.vi"
| datatype =s
| description =The paths of recently opened VIs, CTLs.
| permitted_values =Paths to *.vi, *.ctl
| default = <blank> or no key
| LV1 = 8
| LV2 = 20xx
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname =RecentFiles.projectPathList
| example =RecentFiles.projectPathList="C:\Projects\Project 1\Project 1.lvproj;C:\Projects\Project 2\Project 2.lvproj"
| datatype =s
| description =The paths of recently opened projects.
| permitted_values =Paths to *.lvproj
| default = <blank> or no key
| LV1 = 8
| LV2 = 20xx
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

[[Category:Configuration File]]

LabVIEW configuration file/Block Diagram

2024-01-02T16:06:55Z

Playerm1: minor updates to resizeObjectsOnBlockDiagram entry. LV version update, note update.

This is a list of LabVIEW ini File settings relating to Block Diagram behaviour.

{{TOCnestright}}

{{ labviewconfigurationkey
| keyname = allowDragDropFromFileDlg
| example = allowDragDropFromFileDlg=TRUE
| datatype = b
| description = Enables drag and drop functionality from the file dialog to the block diagram of a vi
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 = 8.5
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = This functionality existed in LV 5.0 -> LV 7.1, was removed in LV 8.x, and added back in as an ini setting in 8.5
}}
{{ labviewconfigurationkey
| keyname = allowOpenFPOfInstanceVIs
| example = allowOpenFPOfInstanceVIs=TRUE
| datatype = b
| description = Changes the behavior of the Convert Instance VI to Standard VI menu option when right-clicking a malleable VI on the block diagram to instead open the instance VI
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 = 2019 onwards
| OS1 = w
| OS2 = m
| OS3 = l
| notes =
}}
{{ labviewconfigurationkey
| keyname = autoWireMax
| example = autoWireMax=24
| datatype = i
| description = Maximum distance between nodes for autowiring to be active
| permitted_values = 1 to 232
| default = 16
| LV1 =6
| LV2 =7
| LV3 =8
| LV4 =
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = This setting is only effective if [[#enableAutoWire|enableAutoWire]] is set to TRUE
}}
{{ labviewconfigurationkey
| keyname = autoWireMin
| example = autoWireMin=8
| datatype = i
| description = Minimum distance between nodes for autowiring to be active
| permitted_values = 1 to 232
| default = 4
| LV1 = 6
| LV2 = 7
| LV3 = 8
| LV4 =
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = This setting is only effective if [[#enableAutoWire|enableAutoWire]] is set to TRUE
}}
{{ labviewconfigurationkey
| keyname = copyDeleteFPDCOFromFPTerm
| example = copyDeleteFPDCOFromFPTerm=TRUE
| datatype = b
| description = Delete front panel terminals from diagram
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 =
| LV2 = 4
| LV3 = 5
| LV4 = 6
| LV5 = 7
| LV6 = 8
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}

{{ labviewconfigurationkey
| keyname = enableAutoWire
| example = enableAutoWire=FALSE
| datatype = b
| description = Enables automatic wire routing. This key is set by the [[Options dialog]] for ''Enable automatic wire routing'' in section [[Block Diagram options#Wiring|Wiring]] under category [[Block Diagram options|Block Diagram]].
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 = 6
| LV2 = 7
| LV3 = 8
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
}}

{{ labviewconfigurationkey
| keyname = FancyFPTerms
| example = FancyFPTerms=FALSE
| datatype = b
| description = Enables placing front panel terminals as icons. This key is set by the [[Options dialog]] for ''Place front panel terminals as icons'' in section [[Block Diagram options#General|General]] under category [[Block Diagram options|Block Diagram]].
| permitted_values = TRUE or FALSE
| default = (Depends on LV Version)
| LV1 = 7
| LV2 = 8
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
}}

{{ labviewconfigurationkey
| keyname = funkyErrClustWire
| example = funkyErrClustWire=FALSE
| datatype = b
| description = Change Error Cluster wires color from the standard cluster pink to a more distinctive brown/green color
| permitted_values = TRUE or FALSE
| default = LabVIEW 5.1, 6.x, 7.x: FALSE, LabVIEW 8.x: TRUE
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = inlineSubVIEnabled
| example = inlineSubVIEnabled=FALSE
| datatype = b
| description = Allows the context menu item "Inline SubVI" on any SubVI which inserts the code directly into the block diagram containing the SubVI.
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 = 6
| LV2 = 7
| LV3 = 8
| LV4 =
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = maxUndoSteps
| example = maxUndoSteps=50
| datatype = i
| description = Maximum undo steps per VI
| permitted_values = 1 to 99
| default = 8
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = resizeObjectsOnBlockDiagram
| example = resizeObjectsOnBlockDiagram=TRUE
| datatype = b
| description = Enables "Resize Objects" functionality on the block diagram of a vi.
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 = 2015 onward
| OS1 = w
| notes = Mainly useful for resizing objects on the structures palette, comment boxes, and labels.
}}
{{ labviewconfigurationkey
| keyname = showBDConstName
| example = showBDConstName=TRUE
| datatype = b
| description = Show Constant Label with name of terminal when creating from a terminal
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 =4
| LV2 =5
| LV3 =6
| LV4 =7
| LV5 =8
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}

{{ labviewconfigurationkey
| keyname = ShowRedXOnWire
| example = ShowRedXOnWire=TRUE
| datatype = b
| description = Shows a red "X" (and directional arrows) on top of a broken wire.
| permitted_values = TRUE or FALSE
| default = TRUE
| OS1 = w
| OS2 = m
| OS3 = l
}}

{{ labviewconfigurationkey
| keyname = showSubVIName
| example = showSubVIName=TRUE
| datatype = b
| description = Show subVI names when dropped
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 =4
| LV2 =5
| LV3 =6
| LV4 =7
| LV5 =8
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = showTipStringsOnTerms
| example = showTipStringsOnTerms=FALSE
| datatype = b
| description = Show tip-strips over terminals
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 =4
| LV2 =5
| LV3 =6
| LV4 =7
| LV5 =8
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = showWireDots
| example = showWireDots=TRUE
| datatype = b
| description = Show dots at wire junctions
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 =7
| LV2 =8
| LV3 =
| LV4 =
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = showWireGuides
| example = showWireGuides=FALSE
| datatype = b
| description = Show dashed line while wiring
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 =4
| LV2 =5
| LV3 =6
| LV4 =7
| LV5 =8
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = structuresFadeToDiagramBeneath
| example = structuresFadeToDiagramBeneath=FALSE
| datatype = b
| description = Makes the diagram of structures semi-transparent so that you can see objects behind them.
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 =6
| LV2 =7
| LV3 =8
| LV4 =
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = Enabling this setting will slow down the development environment on large Block Diagrams. Feature disabled in LabVIEW 2014 onwards.
}}
{{ labviewconfigurationkey
| keyname = transparentBDLabels
| example = transparentBDLabels=TRUE
| datatype = b
| description = Use transparent name labels
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 =5
| LV2 =6
| LV3 =7
| LV4 =8
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = UseNumbersForNewVIIcons
| example = UseNumbersForNewVIIcons=FALSE
| datatype = b
| description = Tells LabVIEW whether to automatically include a number (1-9) in the lower-right corner of each new VI's icon.
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 = 8.6
| LV2 =
| LV3 =
| LV4 =
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =
| notes = This key replaces [[#UseNumbersForNewVIIconsInLibs|UseNumbersForNewVIIconsInLibs]] from LabVIEW 8.5.
}}
{{ labviewconfigurationkey
| keyname = UseNumbersForNewVIIconsInLibs
| example = UseNumbersForNewVIIconsInLibs=FALSE
| datatype = b
| description = Tells LabVIEW whether to automatically include a number (1-9) in the lower-right corner of each new VI's icon for VIs created inside libraries (.lvlib, .lvclass, .xctl, .lvsc, etc).
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 = 8.5
| LV2 =
| LV3 =
| LV4 =
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =
| notes = This key was replaced by [[#UseNumbersForNewVIIcons|UseNumbersForNewVIIcons]] in LabVIEW 8.6.
}}
{{ labviewconfigurationkey
| keyname = viCaptionTipStrings
| example = viCaptionTipStrings=FALSE
| datatype = b
| description = Use control captions for subVI tip-strips
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 =5
| LV2 =6
| LV3 =7
| LV4 =8
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = SourceOnlyEnvironment
| example = SourceOnlyEnvironment=True
| datatype = b
| description = The option "Separate Compiled Code from Source" is turned on by default
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 =10
| LV2 =
| LV3 =
| LV4 =
| LV5 =
| LV6 =
| OS1 = w
| OS2 =
| OS3 =
| OS4 =
| notes = Currently this causes "uncomfortably" slow load times when opening a large number of VIs which this option enabled. Reference, [https://decibel.ni.com/content/groups/large-labview-application-development/blog/2010/09 NI forums]
}}

[[Category:Configuration File|Block Diagram]]

LabVIEW configuration file/Block Diagram

2024-01-02T14:51:57Z

Playerm1: added entry for LabVIEW.ini token "resizeObjectsOnBlockDiagram"

This is a list of LabVIEW ini File settings relating to Block Diagram behaviour.

{{TOCnestright}}

{{ labviewconfigurationkey
| keyname = allowDragDropFromFileDlg
| example = allowDragDropFromFileDlg=TRUE
| datatype = b
| description = Enables drag and drop functionality from the file dialog to the block diagram of a vi
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 = 8.5
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = This functionality existed in LV 5.0 -> LV 7.1, was removed in LV 8.x, and added back in as an ini setting in 8.5
}}
{{ labviewconfigurationkey
| keyname = allowOpenFPOfInstanceVIs
| example = allowOpenFPOfInstanceVIs=TRUE
| datatype = b
| description = Changes the behavior of the Convert Instance VI to Standard VI menu option when right-clicking a malleable VI on the block diagram to instead open the instance VI
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 = 2019 onwards
| OS1 = w
| OS2 = m
| OS3 = l
| notes =
}}
{{ labviewconfigurationkey
| keyname = autoWireMax
| example = autoWireMax=24
| datatype = i
| description = Maximum distance between nodes for autowiring to be active
| permitted_values = 1 to 232
| default = 16
| LV1 =6
| LV2 =7
| LV3 =8
| LV4 =
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = This setting is only effective if [[#enableAutoWire|enableAutoWire]] is set to TRUE
}}
{{ labviewconfigurationkey
| keyname = autoWireMin
| example = autoWireMin=8
| datatype = i
| description = Minimum distance between nodes for autowiring to be active
| permitted_values = 1 to 232
| default = 4
| LV1 = 6
| LV2 = 7
| LV3 = 8
| LV4 =
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = This setting is only effective if [[#enableAutoWire|enableAutoWire]] is set to TRUE
}}
{{ labviewconfigurationkey
| keyname = copyDeleteFPDCOFromFPTerm
| example = copyDeleteFPDCOFromFPTerm=TRUE
| datatype = b
| description = Delete front panel terminals from diagram
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 =
| LV2 = 4
| LV3 = 5
| LV4 = 6
| LV5 = 7
| LV6 = 8
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}

{{ labviewconfigurationkey
| keyname = enableAutoWire
| example = enableAutoWire=FALSE
| datatype = b
| description = Enables automatic wire routing. This key is set by the [[Options dialog]] for ''Enable automatic wire routing'' in section [[Block Diagram options#Wiring|Wiring]] under category [[Block Diagram options|Block Diagram]].
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 = 6
| LV2 = 7
| LV3 = 8
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
}}

{{ labviewconfigurationkey
| keyname = FancyFPTerms
| example = FancyFPTerms=FALSE
| datatype = b
| description = Enables placing front panel terminals as icons. This key is set by the [[Options dialog]] for ''Place front panel terminals as icons'' in section [[Block Diagram options#General|General]] under category [[Block Diagram options|Block Diagram]].
| permitted_values = TRUE or FALSE
| default = (Depends on LV Version)
| LV1 = 7
| LV2 = 8
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
}}

{{ labviewconfigurationkey
| keyname = funkyErrClustWire
| example = funkyErrClustWire=FALSE
| datatype = b
| description = Change Error Cluster wires color from the standard cluster pink to a more distinctive brown/green color
| permitted_values = TRUE or FALSE
| default = LabVIEW 5.1, 6.x, 7.x: FALSE, LabVIEW 8.x: TRUE
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = inlineSubVIEnabled
| example = inlineSubVIEnabled=FALSE
| datatype = b
| description = Allows the context menu item "Inline SubVI" on any SubVI which inserts the code directly into the block diagram containing the SubVI.
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 = 6
| LV2 = 7
| LV3 = 8
| LV4 =
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = maxUndoSteps
| example = maxUndoSteps=50
| datatype = i
| description = Maximum undo steps per VI
| permitted_values = 1 to 99
| default = 8
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = resizeObjectsOnBlockDiagram
| example = resizeObjectsOnBlockDiagram=TRUE
| datatype = b
| description = Enables "Resize Objects" functionality on the block diagram of a vi.
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 = 2018 onward
| OS1 = w
| notes = Tested with 2018 SP1, Windows 10
}}
{{ labviewconfigurationkey
| keyname = showBDConstName
| example = showBDConstName=TRUE
| datatype = b
| description = Show Constant Label with name of terminal when creating from a terminal
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 =4
| LV2 =5
| LV3 =6
| LV4 =7
| LV5 =8
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}

{{ labviewconfigurationkey
| keyname = ShowRedXOnWire
| example = ShowRedXOnWire=TRUE
| datatype = b
| description = Shows a red "X" (and directional arrows) on top of a broken wire.
| permitted_values = TRUE or FALSE
| default = TRUE
| OS1 = w
| OS2 = m
| OS3 = l
}}

{{ labviewconfigurationkey
| keyname = showSubVIName
| example = showSubVIName=TRUE
| datatype = b
| description = Show subVI names when dropped
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 =4
| LV2 =5
| LV3 =6
| LV4 =7
| LV5 =8
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = showTipStringsOnTerms
| example = showTipStringsOnTerms=FALSE
| datatype = b
| description = Show tip-strips over terminals
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 =4
| LV2 =5
| LV3 =6
| LV4 =7
| LV5 =8
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = showWireDots
| example = showWireDots=TRUE
| datatype = b
| description = Show dots at wire junctions
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 =7
| LV2 =8
| LV3 =
| LV4 =
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = showWireGuides
| example = showWireGuides=FALSE
| datatype = b
| description = Show dashed line while wiring
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 =4
| LV2 =5
| LV3 =6
| LV4 =7
| LV5 =8
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = structuresFadeToDiagramBeneath
| example = structuresFadeToDiagramBeneath=FALSE
| datatype = b
| description = Makes the diagram of structures semi-transparent so that you can see objects behind them.
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 =6
| LV2 =7
| LV3 =8
| LV4 =
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = Enabling this setting will slow down the development environment on large Block Diagrams. Feature disabled in LabVIEW 2014 onwards.
}}
{{ labviewconfigurationkey
| keyname = transparentBDLabels
| example = transparentBDLabels=TRUE
| datatype = b
| description = Use transparent name labels
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 =5
| LV2 =6
| LV3 =7
| LV4 =8
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = UseNumbersForNewVIIcons
| example = UseNumbersForNewVIIcons=FALSE
| datatype = b
| description = Tells LabVIEW whether to automatically include a number (1-9) in the lower-right corner of each new VI's icon.
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 = 8.6
| LV2 =
| LV3 =
| LV4 =
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =
| notes = This key replaces [[#UseNumbersForNewVIIconsInLibs|UseNumbersForNewVIIconsInLibs]] from LabVIEW 8.5.
}}
{{ labviewconfigurationkey
| keyname = UseNumbersForNewVIIconsInLibs
| example = UseNumbersForNewVIIconsInLibs=FALSE
| datatype = b
| description = Tells LabVIEW whether to automatically include a number (1-9) in the lower-right corner of each new VI's icon for VIs created inside libraries (.lvlib, .lvclass, .xctl, .lvsc, etc).
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 = 8.5
| LV2 =
| LV3 =
| LV4 =
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =
| notes = This key was replaced by [[#UseNumbersForNewVIIcons|UseNumbersForNewVIIcons]] in LabVIEW 8.6.
}}
{{ labviewconfigurationkey
| keyname = viCaptionTipStrings
| example = viCaptionTipStrings=FALSE
| datatype = b
| description = Use control captions for subVI tip-strips
| permitted_values = TRUE or FALSE
| default = TRUE
| LV1 =5
| LV2 =6
| LV3 =7
| LV4 =8
| LV5 =
| LV6 =
| OS1 = w
| OS2 = m
| OS3 = l
| OS4 = u
| notes = None
}}
{{ labviewconfigurationkey
| keyname = SourceOnlyEnvironment
| example = SourceOnlyEnvironment=True
| datatype = b
| description = The option "Separate Compiled Code from Source" is turned on by default
| permitted_values = TRUE or FALSE
| default = FALSE
| LV1 =10
| LV2 =
| LV3 =
| LV4 =
| LV5 =
| LV6 =
| OS1 = w
| OS2 =
| OS3 =
| OS4 =
| notes = Currently this causes "uncomfortably" slow load times when opening a large number of VIs which this option enabled. Reference, [https://decibel.ni.com/content/groups/large-labview-application-development/blog/2010/09 NI forums]
}}

[[Category:Configuration File|Block Diagram]]

Design Pattern Case Study: A Simple Counter

2019-04-10T14:20:38Z

Playerm1: /* Queued Message Handler (QMH) */

''by Quentin"Q" Alldredge, Q Software Innovations, LLC''

'''What design pattern should I choose?''' The design pattern you choose is highly dependent on the project requirements. Here is a case study implementing a simple counter in many of the design patterns described in the [[Design Patterns Overview]] page.
[[File:Design Pattern Scale.png|800x800px|frameless|center|Design Pattern Scale]]

== Source code ==
All of the source code is available at:

[https://gitlab.com/QSI_Shared_Code/simple-counter-case-study.git QSI Shared Code on GitLab for LabVIEW 2018]
[https://gitlab.com/QSI_Shared_Code/simple-counter-case-study/tree/LabVIEW2015Version For LabVIEW 2015]

== Requirements ==
The Program Shall:
* Provide a way to allow the user to choose between '''Increment''' and '''Decrement'''
* Provide a way to allow the user to Stop the program
* Provide an I32 Numeric Input called '''Amount'''
* Provide an I32 Numeric Output called '''Count'''
* When '''Increment '''is clicked, add '''Amount''' to the '''Count'''
* When '''Decrement''' is clicked, subtract '''Amount''' from the '''Count'''
* The UI must look like this (title can be different):
[[File:Design Pattern Case Study - Simple Counter UI.png|528x528px|thumb|center|Simple Counter User Interface]]

== State Machine ==
The '''[[State Machine]]''' polls for user input which changes the state to ''Increment'' or ''Decrement''. If both are FALSE the state is transitioned to ''Idle''. A ''Wait'' is required but was made small to prevent any lag which the user could see. Undefined states cause an error and the loop to stop.
[[File:Design Pattern Case Study - State Machine.png|700x700px|thumb|center|Simple Counter implemented using the State Machine Design Pattern]]
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
|+State Machine Pros and Cons
!Pros
!Cons
|-
|Simple to map flow in a flowchart and create
|Either used with no UI or has to poll for user interactions which requires a Wait function to keep from taxing the processor
|-
|Simple to extend by adding cases and modifying state transitions
|Not meant for multiple processes that have to run at different rates
|-
|
|Can't handle the window close button (disabled in this example) so there has to be something else to end program
|-
|
|UI becomes unresponsive if code takes a long time to execute
|-
|
|If using Strings to define state, the default case must be handled. It would be better to implement with an enum.
|}

== Event Handler ==
The '''[[Event Handler]]''' operates only when there is user interaction. In this case it is when the user clicks '''Increment''', '''Decrement''', '''Stop''' or the Windows Close button, "X". The code for each operates inside of the Event Structure.
[[File:Design Pattern Case Study - Event Handler.png|700x700px|thumb|center|Simple Counter implemented using the Event Handler Design Pattern]]
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
|+Event Handler Pros and Cons
!Pros
!Cons
|-
|Does not have to poll for user interactions which reduces processor resources
|Completely dependent on user interactions
|-
|Can handle the windows close button event
|Not meant for multiple processes that have to run at different rates
|-
|
|UI becomes unresponsive if code takes a long time to execute
|}

== Master/Slave ==
The '''[[Master/Slave]]''' separates the Event Handling into the Master Loop and the Data Processing into the Slave Loop. All the Master Loop does is issue commands while the Slave Loop executes those commands. If the Slave receives a command it doesn't know how to do it does nothing. The communication between them is a Notifier which is lossy, it can only send one command at a time. If a command is sent too quickly, it could be lost.
[[File:Design Pattern Case Study - Master-Slave.png|700x700px|thumb|center|Simple Counter implemented using the Master/Slave Design Pattern]]
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
|+Master/Slave Pros and Cons
!Pros
!Cons
|-
|Does not have to poll for user interactions which reduces processor resources
|Commands issued too quickly can be lost
|-
|Can handle the windows close button event
|If using Strings to define commands, the default case must be handled. It would be better to implement with an enum.
|-
|Separates UI from code execution to keep it responsive
| Commands do not have data or what to execute. It is up to the Slave Loop about what to do with each command.
|-
|Can have multiple Slave Loops
|
|}

== Producer/Consumer ==
The '''[[Producer/Consumer]]''' is closely related to the Master/Slave but instead of issuing commands the Producer/Consumer produces data in the Producer Loop which is the used, or consumed, in the Consumer Loop. The communication between them is a Queue which is will buffer the data so that none of it is lost.
[[File:Design Pattern Case Study - Producer-Consumer.png|700x700px|thumb|center|Simple Counter implemented using the Producer/Consumer Design Pattern]]
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
|+Producer/Consumer Pros and Cons
!Pros
!Cons
|-
|Does not have to poll for user interactions which reduces processor resources
|Can't have multiple Consumer Loops
|-
|Can handle the windows close button event and other events
|The structure of data is set for the Consumer Loop.
|-
|Separates UI from code execution to keep it responsive
| It is up to the Consumer Loop about what to do with the data.
|-
|Buffers data so that none is lost
|
|}
== Action Engine (AE) ==
The '''[[Functional global variable|Action Engine (AE)]]''' implementation is similar to the State Machine design pattern. It uses an uninitialized shift register as a memory space for its data (the current count in this case study) and contains the actions to carryout ("Initialize", "Increment", "Decrement", "Stop", and Default'')''. It does not implement the UI requirements and has to be used in an owning program which implements another design pattern. (However, if the above example of a QMH left the Count State shift-register uninitialized, the bottom Message Handling Loop could act as an Action Engine of sorts.)
[[File:Design Pattern Case Study - Action Engine-While Loop.png|700x700px|thumb|center|Simple Counter implemented using the Action Engine Design Pattern (While Loop)]]

[[File:Design Pattern Case Study - Action Engine-For Loop.png|700x700px|thumb|center|Simple Counter implemented using the Action Engine Design Pattern (For Loop)]]

[[File:Design Pattern Case Study - Action Engine-Feedback Node.png|700x700px|thumb|center|Simple Counter implemented using the Action Engine Design Pattern (Feedback Node)]]
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
|+Action Engine Pros and Cons
!Pros
!Cons
|-
|Extensible Can add more actions.
|If using Strings to define action, the default case must be handled. It would be better to implement with an type definition enum.
|-
|Encasulates code to be used in multiple places but operates on the same data
| Not usually used as a stand alone design pattern. Usually doesn't contain UI
|}
== Queued Message Handler (QMH) ==
The '''[[Queued Message Handler|Queued Message Handler (QMH)]]''' design pattern is a combination of Producer/Consumer, Event Handler and State Machine architectures together. It combines the command and data into a Message Queue that serve as the communication between the Event Loop and the Message Handling Loop. The QMH also defines communication back the other direction, from the Message Handling Loop to the Event Loop, through the use of User Events. Unhandled messages cause an error that stops the program.
[[File:Queued Message Handler Design Pattern.png|centre|thumb|700x700px|Simple Counter implemented using the Queued Message Handler Design Pattern]]
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
|+QMH Pros and Cons
!Pros
!Cons
|-
|Does not have to poll for user interactions which reduces processor resources
|Can't have multiple Message Handler Loops
|-
|Can handle the windows close button event and other events
|If using Strings to define command, the default case must be handled. It would be better to implement with an enum.
|-
|Separates UI from code execution to keep it responsive
|
|-
|Bi-directional communication between loops
|
|-
|Each command can have a different structure of data associated with it.
|
|}

== Object-Oriented QMH ==
The '''Object-Oriented QMH''' uses Objects as the messages. These objects are defined by the Message class and include a must override method called Action. The Message Queue, Update Count User Event and Stop User Event are created in the State Initialize Method. Messages are sent using the Message Queue from the Event Loop to the Message Handling Loop where they are dequeued. The dequeued Message then calls its Action Method by dynamic dispatch which performs an Action on the State.
[[File:Design Pattern Case Study - OO QMH.png|center|thumb|700x700px|Simple Counter implemented using the Object-Oriented QMH Design Pattern]]
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
|+OO QMH Pros and Cons
!Pros
!Cons
|-
|Extensible. It is easy to extend functionality by adding a new child of the Message Class.
|Lots of files to manage. Every message is at least three files (Class, Action Method and Send Method).
|-
|Messages contain the command (Class), the data (Class Private Data), and the action (Action Method).
|Does not handle communication between modules without adding another communication method.
|-
|Does not use strings to define commands.
|
|}
== Delacor QMH ==
The '''[[Delacor Queued Message Handler (DQMH)]]''' design pattern is an extension of the QMH. Each module uses the same structure for messages as the QMH (cluster of command string, called ''Message'', and data variant, called Message Data) but this time the queue is wrapped in an class called Message Queue. The DQMH also adds external communication between asynchronously running modules by using User Events. Adding new modules and new events are accomplished through built in scripting tools. A stand alone tester is also created along side each module.

When implementing this example the UI could have been part of the module. However, it seemed more correct to use a variation of the tester that was created as the UI. In this way it shows the user event communication. The design pattern of the tester and subsequently the UI VI is the Event Handler design pattern.

This requires the [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213286 DQMH Tools from the LabVIEW Tools Network].
[[File:Design Pattern Case Study - Simple Counter Module.png|center|thumb|700x700px|Simple Counter implemented using the Delacor QMH Design Pattern (Business Logic Code)]]
[[File:Design Pattern Case Study - Event Handler UI.png|thumb|center|700x700px|Simple Counter implemented using the Delacor QMH Design Pattern (UI Logic Code, Event Handler)]]
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
|+DQMH Pros and Cons
!Pros
!Cons
|-
|Extensible. Extend functionality using built in scripting tools executed from the Tools Menu.
|Lots of auto-generated code with notes not to touch. Accidentally editing some things could break the scripting tools.
|-
|Message creation and handling is managed via the tools.
|Uses strings to define Messages.
|-
|Provides a lot of in code documentation to help know how and where to modify.
|It can be confusing when starting with this framework to know where to add your custom code. Be sure to follow documentation bookmarks.
|-
|Adds external messaging between modules above that of the regular QMH. Which allows for multiple asynchronous processes.
|
|-
|Adds easy testing because a Tester API is created along side all modules
|
|}
== Actor Framework ==
The '''[[Actor Framework]]''' design pattern is very similar to the Object-Oriented QMH. It also uses Objects as the Messages, inheriting from a special Message Class. The Messages also define the command (the message object itself), the data (the private data of the class), the action to carry out (the DO Method), and the way to send the message (the Send Method). The Message Handling Loop is completely abstracted away as the Call to Parent Actor Core Method. Main UI and the State is defined in the override of the Actor Core, shown below.
[[File:Design Pattern Case Study - Actor Framework.png|thumb|center|700x700px|Simple Counter implemented using the Actor Framework Design Pattern]]
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
|+Actor Framework Pros and Cons
!Pros
!Cons
|-
|Extensible. It is easy to extend functionaily by adding a new child of the Message Class.
|Lots of files to manage. Every message is at least three files (Class, Do Method and Send Method).
|-
|Messages contain the command (Class), the data (Class Private Data), and the action (Do Method).
|Difficult to debug. Using [http://www.mooregoodideas.com/actor-framework/monitored-actor/monitored-actor-2-0/ MGIs Monitored Actor] helps.
|-
|Does not use strings to define commands.
| If editing the method a Message is based on, it doesn't update the message. This is fixed with [http://www.mooregoodideas.com/actor-framework/AF-Message-maker/ MGIs Improved Actor Framework Message Maker].
|-
|Similar to the OO QMH but adds external messaging between modules. Which allows for multiple asynchronous processes.
|It can be confusing when starting with this framework to know where to add your custom code.
|-
|Only one communication route. External modules can send the same Messages to a module that it can send to itself.
|
|}

== QControls ==
This is definitely not the best use case for a QControl. '''[[QControls]]''' are Object-Oriented replacements for XControls. However, for science lets try it.

Like the FGV a QControl is not a stand alone operator; therefore, it needs to be in another VI to function. The Increment, Decrement, Amount changing, and the actual Count is handled by the QControl. The Stop button is handled by the owning UI. Count is updated via a User Event started by the QControl. Under the hood its just two Event Handlers; one for the QControl and one for the owning VI. The owning VI could be any design pattern. The QControl should not need anything more than an Event Handler but it could probably be a QMH if necessary.
[[File:Design Pattern Case Study - QControl Event Handler.png|thumb|center|700x700px|QControl, Event Handler]]
[[File:Design Pattern Case Study - QControl Owning VI.png|thumb|center|700x700px|Owning VI, another Event Handler]]

{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
|+QControls Pros and Cons
!Pros
!Cons
|-
|Replaces XControls
|It can be confusing, when starting, to know where to add your custom code. See Help->QSI->QControl Toolkit Help...
|-
|Did I mention it replaces XControls?
|Again, not the best use case for QControls.

[[Category:Design patterns]]
[[Category:Object-Oriented Programming]]
[[Category:Actor Framework]]
[[Category:QControl]]

VI Icon

2019-03-03T17:04:09Z

Playerm1: /* How to Make icons smaller than the entire square */

{{update}}

== VI Icon Importance ==
The icon you use to represent your subVI can tell you or other developers a lot about what the subVI does without ever having to open the subVI. Taking the time to create at least simple text VI icon is a requirement when sharing code between developers. The use of images in VI icons can also enhance their meaning when text can't be used because of length or in cases where code is shared across different spoken languages. National Instruments keeps an [http://www.ni.com/devzone/idnet/library/icon_art_glossary.htm Icon Art Glossary] to help developers who are less experienced making easy to recognize icons.

== How to Make icons smaller than the entire square ==
Sometimes it is desirable to make a LabVIEW subVI's icon smaller than the normal 32x32 pixels. National Instruments has done this with several primitives and has made it possible for end users to make custom icons of any size for a subVI. It is good practice to ensure that terminals used line up logically with the borders of the smaller VI created.

Starting with a typical icon editor 
[[Image:Typical_icon_editor.png]] 
 
Clear the default icon from the 256 icon, then click on the "Show Terminals" checkbox. Draw a box, around the terminals you wish to have displayed on your custom icon. 
[[Image:Icon_editor_with_small_icon.png]] 
Fill the 256 color icon with a color of your choice, as well as any words or symbols you wish to use to describe your subVI's work, then copy the subVI to the black and white icon by selecting the black and white icon and pressing the copy from 256 color button on the right. 
[[Image:Icon_editor_with_all_small_icons.png]] 

You can even make irregularly shaped icons. The white area outside will be transparent in your diagrams. Interestingly, if the border you define is not contiguous, the inside of your icon will also be transparent (you can see a wire go all the way to its connection point (visible as a little cross in the "show terminals" icon view). You can actually have multiple non-transparent areas in your icons if you wish.
 '''NOTE:''' White space icon transparency is lost if a VI edited in this way is used from within a Packed Project Library (PPL) distribution. The icon placed on a block diagram from a PPL reverts to its original 32x32 icon area with white fill in place of transparencies. This is the case for LabVIEW IDE versions as recent as 2017 SP1.

== Other icon tricks ==
===Double Click===
There are certain tools in the icon editor that are "double-clickable". Double clicking on the selection, filled box, and empty box tool icons in the editing palette will apply that tool to the entire icon square. Double clicking on the font tool will bring up a font dialog for selecting font name, size, color, justification, and style (bold, italics, etc).

[[Image:Double_Clickable_Icon_Editor_tools.png]]

===Move text===
While typing a text into the Icon Editor the text is movable by using the arrow keys on the keyboard.

== Alternative Icon Editors ==
As of LabVIEW 8.0 a custom icon editor could be built and called from LabVIEW to edit icons of VIs. The relevant information to replace the built in VI icon editor is available [http://forums.lavag.org/index.php?s=&showtopic=3320&view=findpost&p=12920 here].

[[Category:LabVIEW fundamentals]]
[[Category:Calling a VI]]

Tree View

2019-03-03T16:39:28Z

Playerm1:

== Setting the icons of an ActiveX tree view control ==
First, create two ActiveX containers on the front panel. Place the TreeView in one and put an ImageList in the other. Second, right-click on the ImageList and bring up the editing dialog by selecting either Property Browser or ImageList|Properties (I suggest the latter). Thirdly, use the editing dialog to paste in the images you want and set any other properties. Fourthly, on the block diagram set the ImageList property of the TreeView to be the ImageList. Lastly, select the images by name or number for each Tree node.

[[Category:User interface]]

Actor Framework is not as hard as you think and here is why…

2019-02-13T19:37:43Z

Playerm1: /* 3. Override the Actor Core, Pre-Launch Init, Handle Error, and Stop Core */

''by Quentin"Q" Alldredge, Q Software Innovations, LLC''<blockquote>This started due to a conversation I had at a Users' Group. I stated during my presentation that the Actor Framework is not as hard as everyone makes it and that it really is just an Object-Oriented implementation of the Queued Message Handler Design Pattern (this is an oversimplification but the concepts are the same, see [[Actor Oriented Design Patterns]]). One colleague then asked how to make the transition. Hopefully this article will answer that question. </blockquote><blockquote>If you are familiar with the [[Queued Message Handler|Queued Message Handler (QMH) Design Pattern]] and [[Object-Oriented Programming|Object-Oriented Programming (OOP)]] then you already know everything you need to start with [[Actor Framework]]. The purpose of this article is to show the parts of the Actor Framework that are comparable to the QMH Design Pattern and provide a step-by-step procedure for converting a QMH project to an Actor Framework project.</blockquote>

__TOC__

== Queued Message Handler (QMH) ==
First let’s define the basic parts of the [[Queued Message Handler|QMH Design Pattern]].

The basic components of a QMH is:
* The Message Cluster
* The Event Handler Loop (EHL)
* The Message Handler Loop (MHL)
* A Queue to communicate Messages from the EHL to the MHL
* User Events to communicate back from the MHL to the EHL
Below is a basic program created using the QMH Design Pattern.
[[File:Queued Message Handler Design Pattern.png|centre|thumb|700x700px|Queued Message Handler Design Pattern]]

=== The Message Cluster ===
The Message Cluster is the structure of a Message to be sent
from the EHL to the MHL. The Message
Cluster contains two parts:
# something to define the Message Type (usually a string or enum)
# something to define the Message Data (usually a variant)
It is this cluster that defines the data type of the Message Queue.

=== The Event Handler Loop (EHL) ===
The
Event Handler Loop (EHL) enqueues the Messages based on the execution UI Events
or User Events. The EHL consist of a
standard Event Handler Design Pattern with an Event Structure and While
Loop. The Event Structure could register
for User Events that serve as communication back from the MHL.

=== The Message Handler Loop (MHL) ===
The Message Handler Loop (MHL) dequeues the Messages and executes the Message based on Message Type. Inside of the case for the Message Type, the Message Data is unflattened accordingly and used to execute the case.

==== EHL to MHL Communication ====
Communication from the EHL to the MHL is through a queue created with the Message Cluster as the data type. This queue created in the initialization step before the EHL and MHL are started.

==== MHL to EHL Communication ====
Communication from the MHL to the EHL is through one or more User Events of whatever data type is needed. These User Events are created in the initialization step before the EHL and MHL are started.

== Actor Framework (AF) ==
The Actor Framework is just the QMH without having to create your own MHL and Message Queue.
[[File:QMH to AF Components.png|577x577px|thumb|center|Comparison of QMH to AF Components]]
Your main code will exist in a Class you create and inherit from the Actor Class. The main code exists in the Actor Core Method which is an override of the method in the parent Actor Class.

Translating the QMH code to AF code now looks like this:
[[File:Design_Pattern_Case_Study_-_Actor_Framework.png|centre|thumb|700x700px|Actor Framework QMH Design Pattern]]

=== The Message Class ===
The Message Cluster becomes the Message Class. Each Message Type becomes its own class that inherits from the parent Message Class. The Message Data becomes the Private Data of these classes.

Message Classes includes two main methods:
# The Do Method contains the code executed when the Message is sent
# The Send Method is the code that enqueues the Message

=== The Event Helper Loop ===
The EHL becomes the Event Helper Loop in the Actor Core Method. It still enqueues Messages based on the execution UI Events or User Events and still consists of a standard Event Handler Design Pattern with an Event Structure and While Loop. The only difference is the queue that is used.

=== The Call to Parent Actor Core and Do Methods ===
Under the Hood in the Actor Framework the parent Actor Core Method consists of a loop that dequeues incoming Messages and dynamically dispatches the Do Method.

The code in the Case Structure that would have been in the MHL becomes overridden methods in the Message Classes. These methods are called the Do Method. The Do Method wraps a method of the Actor Class that executes the code based on the Message.

To enqueue a message do the following:
# Read the queue from the Actor Class using the built-in method “Read Self Enqueuer”
# Use the Send Method created for each Message to enqueue the Message
If updated data is sent with the Message, there will be inputs for it in the Send Methods

=== Event Helper Loop to Parent Actor Core Communication ===
Communication from the Event Helper Loop to Parent Actor Core is through a queue that is created by the Actor Framework (AF). Its data type is the parent Message Class where any child of the Message Class can also be enqueued. The Message queue is obtained by the AF method “Read Self Enqueuer”.

=== Parent Actor Core to Event Helper Loop Communication ===
Communication from the Parent Actor Core to Event Helper Loop Communication is through one or more User Events of whatever data type is needed, just like the QMH Design Pattern. These User Events can be created in the overridden Actor Core Method before the EHL and MHL are started, or in another method called the “Pre-Launch Init” Method which is guaranteed to run before the Actor Core Method.

== Converting QHM to AF ==
So now, I have a QMH Program that I want to convert to AF. What should I do?

Well, it is probably easier to start with AF that to convert but here are the steps to take if you were to do this:

=== 1. Create your Actor Class ===
This has become significantly easier in LabVIEW 2018 (before LabVIEW 2018 view documentation). To create an Actor simply right-click on My Computer in the Project Explorer and select '''New-->Actor'''.
[[File:QMH_to_AF_Step_1a.png|centre|thumb|314x314px|New Actor Shortcut Menu Item]]
Next, give your actor a name.
[[File:QMH_to_AF_Step_1b.png|centre|thumb|420x420px|Give Actor a Name]]
Select where to inherit from. Most likely you will only have one choice unless you have other tools installed. (I like using MGI’s Monitored Actor for debugging purposes.)
[[File:QMH_to_AF_Step_1c.png|centre|thumb|420x420px|Select where to inherit from.]]
Click OK.

A library, class and two virtual folders will be created for you.
[[File:QMH_to_AF_Step_1d.png|centre|thumb|360x360px|Project after Actor is created.]]

=== 2. Add your QMH VI and all SubVIs to the Class ===
Find your code for your QMH and add it to the Actor. You can organize SubVIs later.
[[File:QMH_to_AF_Step_2.png|centre|thumb|360x360px|Add original code to Actor]]

=== 3. Override the Actor Core, Pre-Launch Init, Handle Error, and Stop Core ===
Right-click on your Actor and select '''New-->VI for Override…'''
[[File:QMH_to_AF_Step_3a.png|centre|thumb|436x436px|Select New VI from Override Shortcut Menu Item]]
Select Actor Core, Pre-Launch Init, Handle Error, and Stop Core and click OK. A VI will be created for each of these which we’ll edit in the next steps.
[[File:QMH_to_AF_Step_3b.png|centre|thumb|346x346px|Select VIs to Override]]

=== 4. Edit Pre-Launch Init ===
Edit the Pre-Launch Init Method to add the Create User Event code. Add the User Event references to the Actor Class Private Data so they can be bundled into the class. The Private Data and code should look like this:
[[File:QMH_to_AF_Step_4a.png|centre|thumb|155x155px|Add User Event References to Class Private Data]]
[[File:QMH_to_AF_Step_4b.png|centre|thumb|601x601px|Create the User Event Reference and Bundle into Class]]

=== 5. Edit Stop Core ===
Edit the Stop Core to send the Stop Event and close the User Event references.
[[File:QMH_to_AF_Step_5.png|centre|thumb|618x618px|Stop User Events in Stop Core]]

=== 6. Add State Data to Actor Private Data ===
Your state data, if you have any, should be stored in the Actor and only manipulated in the Actor’s methods.

For this example, my state data was the “Count” and was stored in a shift register in the MHL.
[[File:QMH_to_AF_Step_6a.png|centre|thumb|398x398px|State data in QMH]]
I’ll add this to my Class Private Data.
[[File:QMH_to_AF_Step_6b.png|centre|thumb|197x197px|Added "Count" to Class Private Data]]

=== 7. Create the Message Methods ===
This might be the only real tricky part because this is the main business logic of your code. For this example, my MHL had four cases in it:
# Default – for unhandled string commands (won’t be needed in the AF version)
# Increment – for adding amount to the number
# Decrement – for subtracting amount from the number
# Stop – stopping the MHL and sending user event to the EHL (won’t be needed in the AF version because the “Stop Core.vi” handles this)
So, I need to create two methods for Increment and Decrement. These methods are almost identical. Make sure to include “Amount” as an input in the Connector Pane.
[[File:QMH_to_AF_Step_7a.png|centre|thumb|579x579px|Front Panel of Increment.vi (Decrement.vi is exactly the same)]]
[[File:QMH_to_AF_Step_7b.png|centre|thumb|700x700px|Block Diagram of Increment.vi]]
[[File:QMH_to_AF_Step_7c.png|centre|thumb|700x700px|Block Diagram of Decrement.vi]]
These VIs perform the operation on the state data and the send a User Event to update the count in the UI. This is exactly how the MHL cases performed.

=== 8. Create the Messages ===
Creating Messages from the Increment and Decrement methods is accomplished through the Message Maker in the Tools Menu ('''Tools-->Actor Framework Message Maker''', I use MGI’s version of this tool because of the added features or better icons and the ability to update previously created messages).
[[File:QMH_to_AF_Step_8a.png|centre|thumb|288x288px|Message Creation Tool]]
In the Actor Framework Message Marker (MGI) Dialog, select the methods and click '''Build/Update Selected Message(s)'''.
[[File:QMH_to_AF_Step_8b.png|centre|thumb|505x505px|Select Methods to make into Messages]]
The Message Classes, the Do Methods, and the Send Methods will be created.

Click “X” to close the dialog.

=== 9. Edit the Actor Core ===
My Project now looks like this:
[[File:QMH_to_AF_Step_9a.png|centre|thumb|574x574px|Project after Messages were created.]]
Now it is time to create the Event Helper Loop in the Actor Core.vi. You can copy over the EHL into the “Actor Core.vi”. Shown below with some organization.
[[File:QMH_to_AF_Step_9b.png|centre|thumb|700x700px|Copying the EHL from the QMH]]
Now add in the Message Queue by using the AF method “Read Self Enqueuer” and add the User Event Registration.
[[File:QMH_to_AF_Step_9c.png|centre|thumb|700x700px|Adding Message Queue and Event registration]]
Next change the Message enqueuing to the Send methods of the Message Classes for the Increment and Decrement event. For the Stop and Panel Close Events use the built-in AF method, “Send Normal Stop”.
[[File:QMH_to_AF_Step_9d.png|centre|thumb|700x700px|Change Increment Message Cluster to "Send Increment.vi"]]
[[File:QMH_to_AF_Step_9e.png|centre|thumb|700x700px|Change Stop Message Cluster to "Send Normal Stop"]]

=== 10. Create the Launcher ===
An Actor cannot launch itself, so the last part of an AF project is the “Launcher.vi”. This can be named something else and can be disguised as a splash screen or whatever. Use the built-in AF method, “Launch Root Actor” with the “Show Actor Core Front Panel” flag set to TRUE. Run it and everything should run as you would expect.
[[File:QMH_to_AF_Step_10.png|centre|thumb|124x124px|Launch Root Actor]]

== Why use AF over QMH? ==
Bottomline Up Front: Extensibility, Readability, and Maintainability.

Sure Actor Framework had it hang-ups in the beginning like:
* How do I find it to inherit from it?
* How do I create/update Messages?
* How do I debug AF code?
A lot of these problems have been solved in the newer versions of LabVIEW and in addons like the:
* Created Actors from the “New” Shortcut Menu Option
* Message Maker (AF Original or MGI’s)
* MGI’s Monitored Actor
The Main Consideration is This…

When you start to have more that one module in an application or more operations that must happen in parallel or asynchronously then you need a more expandable framework. The Actor Framework is made just for this purpose. Other addon tools expand this further like MGI’s Panel Manager.

[[Category:Design patterns]]
[[Category:Actor Framework]]
[[Category:Object-Oriented Programming]]