Match Regular Expression function - Revision history

MrJim: Edited to remove the phrase, "Primitive Node," which is a faux pas greatly frowned upon by @DNatt.

2026-09-14T23:57:31Z

Edited to remove the phrase, "Primitive Node," which is a faux pas greatly frowned upon by @DNatt.

← Older revision		Revision as of 23:57, 14 September 2026
Line 173:		Line 173:

	== XNode ==		== XNode ==
	This node is an example of how [[XNode]]s are used ~~as a primitive node in~~ LabVIEW. It utilizes the [[AdaptToInputs (XNode Ability)\|AdaptToInputs]], [[Bounds (XNode Ability)\|Bounds]], [[DisplayName (XNode Ability)\|DisplayName]], [[GenerateCode (XNode Ability)\|GenerateCode]], [[GrowInfo (XNode Ability)\|GrowInfo]], [[Help (XNode Ability)\|Help]], [[Image (XNode Ability)\|Image]], [[Initialize (XNode Ability)\|Initialize]], [[Size (XNode Ability)\|Size]], [[Terms (XNode Ability)\|Terms]], and [[UpdateStateWithRef (XNode Ability)\|UpdateStateWithRef]] abilities. The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode\|XNodeWizardMode]] INI flag. Many of the ability VIs are password protected.		This node is an example of how [[XNode]]s are used to implement certain LabVIEW functions. It utilizes the [[AdaptToInputs (XNode Ability)\|AdaptToInputs]], [[Bounds (XNode Ability)\|Bounds]], [[DisplayName (XNode Ability)\|DisplayName]], [[GenerateCode (XNode Ability)\|GenerateCode]], [[GrowInfo (XNode Ability)\|GrowInfo]], [[Help (XNode Ability)\|Help]], [[Image (XNode Ability)\|Image]], [[Initialize (XNode Ability)\|Initialize]], [[Size (XNode Ability)\|Size]], [[Terms (XNode Ability)\|Terms]], and [[UpdateStateWithRef (XNode Ability)\|UpdateStateWithRef]] abilities. The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode\|XNodeWizardMode]] INI flag. Many of the ability VIs are password protected.

	If the user wishes to avoid using an [[XNode]] but retain the same functionality as the Match Regular Expression function, they may elect to substitute "Match Regular Expression_Execute.vi", which contains the core functionality used by the former. This VI is located in the directory, "/vi.lib/regexp/".		If the user wishes to avoid using an [[XNode]] but retain the same functionality as the Match Regular Expression function, they may elect to substitute "Match Regular Expression_Execute.vi", which contains the core functionality used by the former. This VI is located in the directory, "/vi.lib/regexp/".

MrJim: /* History */

2026-09-14T23:53:46Z

History

← Older revision		Revision as of 23:53, 14 September 2026
Line 185:		Line 185:
	! Change(s)		! Change(s)
	\|-		\|-
	\|[[File:~~LV2018~~.png\|frameless\|border\|64x64px\|LabVIEW ~~2018~~\|link=LabVIEW ~~2018~~]]		\|[[File:LV2026.png\|frameless\|border\|64x64px\|LabVIEW 2026\|link=LabVIEW 2026]]
	\|~~More info to come.~~		\|LabVIEW 2026 Q3: Support for UTF-8 Encoding was added
	\|}		\|}

MrJim: Fixed a typo

2026-09-14T23:48:40Z

Fixed a typo

← Older revision		Revision as of 23:48, 14 September 2026
Line 177:		Line 177:
	If the user wishes to avoid using an [[XNode]] but retain the same functionality as the Match Regular Expression function, they may elect to substitute "Match Regular Expression_Execute.vi", which contains the core functionality used by the former. This VI is located in the directory, "/vi.lib/regexp/".		If the user wishes to avoid using an [[XNode]] but retain the same functionality as the Match Regular Expression function, they may elect to substitute "Match Regular Expression_Execute.vi", which contains the core functionality used by the former. This VI is located in the directory, "/vi.lib/regexp/".

	Within the XNode that comprises each instance of the ~~March~~ Regular Expression function on a block diagram, an internal library call implements the PCRE engine functionality. Given that UTF-8 encoding introduced polymorphism to the function, the underlying method invoked by the library call differs depending on whether the input strings are represented as UTF-8 or System Encoding.		Within the XNode that comprises each instance of the Match Regular Expression function on a block diagram, an internal library call implements the PCRE engine functionality. Given that UTF-8 encoding introduced polymorphism to the function, the underlying method invoked by the library call differs depending on whether the input strings are represented as UTF-8 or System Encoding.

	== History ==		== History ==

MrJim: Added preliminary documentation for UTF-8 encoding.

2026-09-14T23:47:51Z

Added preliminary documentation for UTF-8 encoding.

← Older revision		Revision as of 23:47, 14 September 2026
Line 39:		Line 39:
	\| '''offset'''		\| '''offset'''
	\| No		\| No
	\| '''offset''' specifies the number of ~~characters~~ into '''input string''' at which the function starts searching for '''search string'''.		\| '''offset''' specifies the number of bytes into '''input string''' at which the function starts searching for '''search string'''.
	\|-		\|-
	! [[File:Error Cluster.png\|link=Error Cluster data type]]		! [[File:Error Cluster.png\|link=Error Cluster data type]]
Line 49:		Line 49:
	\| '''before match'''		\| '''before match'''
	\| No		\| No
	\| '''before match''' returns all the characters before the match.		\| '''before match''' returns all the characters (or bytes) before the match.
	\|-		\|-
	! [[File:String Indicator.png\|link=String data type]]		! [[File:String Indicator.png\|link=String data type]]
	\| '''whole match'''		\| '''whole match'''
	\| No		\| No
	\| '''whole match''' returns all the characters that match the expression entered in '''regular expression'''. Any substring matches the function finds appear in the submatch outputs.		\| '''whole match''' returns all the characters (or bytes) that match the expression entered in '''regular expression'''. Any substring matches the function finds appear in the submatch outputs.
	\|-		\|-
	! [[File:String Indicator.png\|link=String data type]]		! [[File:String Indicator.png\|link=String data type]]
	\| '''after match'''		\| '''after match'''
	\| No		\| No
	\| '''after match''' returns all the characters after the match.		\| '''after match''' returns all the characters (or bytes) after the match.
	\|-		\|-
	! [[File:I32 Indicator.png\|link=I32 data type]]		! [[File:I32 Indicator.png\|link=I32 data type]]
	\| '''offset past match'''		\| '''offset past match'''
	\| No		\| No
	\| '''offset past match''' returns the index in '''input string''' of the first ~~character~~ after the last match. If the VI does not find a match, '''offset past match''' returns –1.		\| '''offset past match''' returns the index in '''input string''' of the first byte after the last match. If the VI does not find a match, '''offset past match''' returns –1.
	\|-		\|-
	! [[File:Error Cluster Indicator.png\|link=Error Cluster data type]]		! [[File:Error Cluster Indicator.png\|link=Error Cluster data type]]
Line 164:		Line 164:
	\| \s \|\| 0x09 0x0A 0x0B 0x0C 0x0D 0x20 \|\| Union of characters included in \h and \v		\| \s \|\| 0x09 0x0A 0x0B 0x0C 0x0D 0x20 \|\| Union of characters included in \h and \v
	\|}		\|}

			== UTF-8 Encoded Strings ==
			In LabVIEW 2026 Q3, support for strings with UTF-8 representation was introduced as an official feature. Many functions were consequently updated to support this encoding, including the Match Regular Expression function. If a string with UTF-8 representation is connected to either or both of the '''Input String''' and/or '''Regular Expression''' terminal, the Match Regular Expression function behaves polymorphically such that it parses UTF-8 encoded strings in a slightly different manner than it parses traditional system-encoded strings.

			In all LabVIEW versions prior to 2026 Q3, there was only a single representation for strings: This was ASCII encoding, where each character in a given string is represented by a single byte. (In LabVIEW's nomenclature, this is referred to as "System Encoding.") In contrast, strings may also now be encoded as UTF-8, wherein each character is represented by one, two, three or four bytes, depending on the character being represented, per [[rfc:3629\|RFC 3629]].

			Due to the fact that a given character represented in UTF-8 may be variable in its byte length, the developer must be aware that, while the values of the '''offset''' and '''offset past match''' terminals still refer to respective offsets in bytes as with System Encoding (i.e. ASCII), with UTF-8 encoding, those byte offsets do not necessarily align with character indices.

	== XNode ==		== XNode ==
	This node is an example of how [[XNode]]s are used as a primitive node in LabVIEW. It utilizes the [[AdaptToInputs (XNode Ability)\|AdaptToInputs]], [[Bounds (XNode Ability)\|Bounds]], [[DisplayName (XNode Ability)\|DisplayName]], [[GenerateCode (XNode Ability)\|GenerateCode]], [[GrowInfo (XNode Ability)\|GrowInfo]], [[Help (XNode Ability)\|Help]], [[Image (XNode Ability)\|Image]], [[Initialize (XNode Ability)\|Initialize]], [[Size (XNode Ability)\|Size]], [[Terms (XNode Ability)\|Terms]], and [[UpdateStateWithRef (XNode Ability)\|UpdateStateWithRef]] abilities. The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode\|XNodeWizardMode]] INI flag. Many of the ability VIs are password protected.		This node is an example of how [[XNode]]s are used as a primitive node in LabVIEW. It utilizes the [[AdaptToInputs (XNode Ability)\|AdaptToInputs]], [[Bounds (XNode Ability)\|Bounds]], [[DisplayName (XNode Ability)\|DisplayName]], [[GenerateCode (XNode Ability)\|GenerateCode]], [[GrowInfo (XNode Ability)\|GrowInfo]], [[Help (XNode Ability)\|Help]], [[Image (XNode Ability)\|Image]], [[Initialize (XNode Ability)\|Initialize]], [[Size (XNode Ability)\|Size]], [[Terms (XNode Ability)\|Terms]], and [[UpdateStateWithRef (XNode Ability)\|UpdateStateWithRef]] abilities. The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode\|XNodeWizardMode]] INI flag. Many of the ability VIs are password protected.

	If the user wishes to avoid using an [[XNode]] but retain the same functionality as the Match Regular Expression function, they may elect to substitute "Match Regular Expression_Execute.vi", which contains the core functionality used by the former. This VI is located in the directory, "/vi.lib/regexp/".		If the user wishes to avoid using an [[XNode]] but retain the same functionality as the Match Regular Expression function, they may elect to substitute "Match Regular Expression_Execute.vi", which contains the core functionality used by the former. This VI is located in the directory, "/vi.lib/regexp/".

			Within the XNode that comprises each instance of the March Regular Expression function on a block diagram, an internal library call implements the PCRE engine functionality. Given that UTF-8 encoding introduced polymorphism to the function, the underlying method invoked by the library call differs depending on whether the input strings are represented as UTF-8 or System Encoding.

	== History ==		== History ==
Line 189:		Line 199:
	* [https://www.pcre.org/original/doc/html/pcresyntax.html PCRE Syntax Manual Page] - More abbreviated official documentation of PCRE pattern syntax		* [https://www.pcre.org/original/doc/html/pcresyntax.html PCRE Syntax Manual Page] - More abbreviated official documentation of PCRE pattern syntax
	* [https://www.debuggex.com/cheatsheet/regex/pcre Debuggex PCRE Cheat Sheet] - A succinct reference for PCRE syntax		* [https://www.debuggex.com/cheatsheet/regex/pcre Debuggex PCRE Cheat Sheet] - A succinct reference for PCRE syntax
			* [https://datatracker.ietf.org/doc/html/rfc3629 UTF-8, a transformation format of ISO 10646] - Provides details and history pertaining to UTF-8 encoding
			* [https://en.wikipedia.org/wiki/UTF-8 UTF-8 Wikipedia Article] - Summarizes the UTF-8 standard

	[[Category:String Palette]]		[[Category:String Palette]]

MrJim: /* Avoiding Stack Overflow */

2026-08-28T23:31:41Z

Avoiding Stack Overflow

← Older revision		Revision as of 23:31, 28 August 2026
Line 117:		Line 117:
	As a general best practice, the developer may also wish to limit the allowable length of the input string to be evaluated by the regular expression.		As a general best practice, the developer may also wish to limit the allowable length of the input string to be evaluated by the regular expression.

	It should also be noted that characters or expressions that form a group need not be ''captured'' as a submatch. To group characters as part of an expression without capturing them as output, they may form a non-capturing group. The syntactical difference is that a non-capturing group includes <code>?:</code> after the opening <code>(</code>. For example, while <code>(ABC)</code> matches the string "ABC" and includes it as a submatch, <code>(?:ABC)</code> likewise groups the characters "ABC" together but does not return them as the value of a ~~substring~~ output.		It should also be noted that characters or expressions that form a group need not be ''captured'' as a submatch. To group characters as part of an expression without capturing them as output, they may form a non-capturing group. The syntactical difference is that a non-capturing group includes <code>?:</code> after the opening <code>(</code>. For example, while <code>(ABC)</code> matches the string "ABC" and includes it as a submatch, <code>(?:ABC)</code> likewise groups the characters "ABC" together but does not return them as the value of a submatch output.

	== Tips and tricks ==		== Tips and tricks ==

MrJim: Major edit of the Details section to provide more detail and clarity. Moved the "Grouping Patterns..." section before the "Avoiding Stack Overflow" section, since stack overflow section refers to captured groups. Changed the format of examples to bulleted lists for readability. Added `markup around code and input strings. Added a detailed explanation of a non-capturing group.`


2026-08-28T23:19:41Z
Major edit of the Details section to provide more detail and clarity. Moved the "Grouping Patterns..." section before the "Avoiding Stack Overflow" section, since stack overflow section refers to captured groups. Changed the format of examples to bulleted lists for readability. Added <code> markup around code and input strings. Added a detailed explanation of a non-capturing group.

				
				
				
				
				
				← Older revision
				Revision as of 23:19, 28 August 2026
				
Line 73:
Line 73:



=== Details === === Details ===
'''Note'''  The Match Regular Expression function does not support null characters in strings. If you include null characters in strings you wire to this function, LabVIEW returns an error and the function may return unexpected results. *This function is used to match one or more substrings in '''input string''' by evaluating a '''regular expression''' against it, where the '''regular expression''' ("regex") follows the standardized syntax defined by the Perl Compatible Regular Expression (PCRE) specification.
*Refer to the PCRE website at [http://www.pcre.org www.pcre.org] for more detailed information about Perl Compatible Regular Expressions.
*From a cursory perspective, the Match Regular Expression node is functionally very similar to the [[Match Pattern function]], but is much more powerful, arguably more versatile, and provides many additional options.
*The Match Regular Expression node executes much more slowly than the [[Match Pattern function]]. When executed relatively infrequently in an application, the difference is negligible, but when scaled and executed repeatedly, there is a noticeable performance penalty. Therefore, if the application does not require the power and complexity afforded by the Match Regular Expression function, the user may elect to use the [[Match Pattern function]] instead.
*Regular expression support is provided by the PCRE library package. Refer to <National Instruments>\_Legal Information directory for more information about the license under which the PCRE library package is redistributed.
'''Note'''  The Match Regular Expression function does not support null characters (i.e. bytes with values of zero) in the input strings. If strings wired to this function include null characters, LabVIEW returns an error and the function may return unexpected results.
 
====Grouping Patterns for Submatches====
In straightforward use cases, the developer may simply rely on the value of the '''whole match''' terminal as the primary output of this function, as they would when using the [[Match Pattern function]]. For more complex use cases, multiple substrings from '''input string''' matching portions of the regular expression may be "captured," or returned separately from '''whole match''' as "submatches."
 
When captured groups are specified within the regex, the entirety of the match is predictably returned as the value of '''whole match''', but smaller portions that are substrings of '''whole match''' are returned on separate output terminals.
 
''<small>In official PCRE parlance, these submatches are referred to as "captured groups." In the LabVIEW documentation for this function, the outputs for these captured groups are referred to as both "substrings" and "submatches" inconsistently.</small>''
 
The additional output terminals referred to as "'''Substring 1'''" .. "'''Substring  n'''" are exposed by dragging the bottom of the function to expand it, similar to the behavior of the [[Scan From String function]]. These outputs are not depicted in the illustration at the top of this article.
 
Within the '''regular expression''', the developer may specify that a portion of the match is to be captured and returned as a separate output by placing a subset of the regex within parentheses.
 
For example:
 
* Suppose <code>Hello LabVIEW!</code> is provided as the value of '''input string'''
* Also suppose that <code>(el.)..(L..)</code> is provided as the value of '''regular expression''', wherein <code>.</code> may match any single character
* Upon execution of the Match Regular Expression function, the value of the '''whole match''' terminal is set to <code>ello Lab</code>
* '''Submatch 1''' then has a value of <code>ell</code>
* '''Submatch 2''' then has a value of <code>Lab</code> 
 
If a captured group is nested within another captured group, the regular expression returns a submatch for the outer group before the inner group.



*Regular expression support is provided by the PCRE library package. Refer to <National Instruments>\_Legal Information directory for more information about the license under which the PCRE library package is redistributed. For example:
*Refer to the PCRE website at [http://www.pcre.org www.pcre.org] for more information about Perl Compatible Regular Expressions.  
*The Match Regular Expression function gives you more options for matching strings but performs more slowly than the [[Match Pattern function]]. * Suppose again that <code>Hello LabVIEW!</code> is provided as the value of '''input string'''
*Use regular expressions (regex) in this function to refine searches. * Also suppose that <code>(.(el.).).(L..)</code> is provided as the value of '''regular expression'''
* Upon execution of the Match Regular Expression function, the value of the '''whole match''' terminal is set to <code>Hello Lab</code>
* '''Submatch 1''' then has a value of <code>Hello</code>
* '''Submatch 2''' has a value of <code>ell</code>
* '''Submatch 3''' has a value of <code>Lab</code>
 
In this example, '''Submatch 1''' is <code>Hello</code> because the regular expression matches the outer character group before the inner group.



====Avoiding Stack Overflow==== ====Avoiding Stack Overflow====
Certain regular expressions that use repeated grouped expressions (such as (.|\s)* or (a*)*) require significant resources to process when applied to large input strings. In some cases a stack overflow may occur on large input strings. Some regular expressions may recurse repeatedly while attempting to match a large string, which may eventually overflow the stack. For example, the regular expression (.|\n)*A and a large input string may cause LabVIEW to crash. To avoid recursion, you can rewrite the regular expression (.|\n)*A as (?s).*A. The (?s) notation indicates that a period matches new lines. You also can rewrite the expression as [^A]*A. Certain regular expressions that use repeated capturing groups (such as <code>(.|\s)*</code> or <code>(a*)*</code> ) require substantial resources to process when evaluated over large input strings, potentially leading to a stack overflow. Expressions involving captured groups that may cause excessive recursion are to be avoided for this reason. For example, evaluating the regular expression <code>(.|\n)*A</code> over a large input string may cause LabVIEW to crash. To avoid recursion, the regular expression <code>(.|\n)*A</code> may be rewritten as <code>(?s).*A</code>. The <code>(?s)</code> flag placed at the start of the regular expression instructs the compiler to include vertical white space characters when matching against the metacharacter, <code>.</code> (a period character in an expression). <code>(.|\n)*A</code> may also be rewritten as <code>[^A]*A</code>, which perhaps unintuitively includes vertical white space when matching characters other than "A" that precede "A".



====Grouping Patterns for Submatches==== As a general best practice, the developer may also wish to limit the allowable length of the input string to be evaluated by the regular expression.
You can capture submatches by placing parentheses ( ) around a portion of a regular expression that you want the function to return as a submatch. For example, the regular expression (el.)..(L..) returns two submatches in the input string Hello LabVIEW!: ell and Lab. Each submatch corresponds to a character group in the order that the character group appears in the regular expression. In this example, '''submatch 1''' is ell and '''submatch 2''' is Lab. 



If you nest a character group within another character group, the regular expression creates a submatch for the outer group before the inner group. For example, the regular expression (.(el.).).(L..) returns three submatches in the input Hello LabVIEW!: Hello, ell, and Lab. In this example, '''submatch 1''' is Hello because the regular expression matches the outer character group before the inner group. It should also be noted that characters or expressions that form a group need not be ''captured'' as a submatch. To group characters as part of an expression without capturing them as output, they may form a non-capturing group. The syntactical difference is that a non-capturing group includes <code>?:</code> after the opening <code>(</code>. For example, while <code>(ABC)</code> matches the string "ABC" and includes it as a submatch, <code>(?:ABC)</code> likewise groups the characters "ABC" together but does not return them as the value of a substring output.



== Tips and tricks == == Tips and tricks ==



MrJim: /* Added Reference, External Links */ Added a reference to the Match Pattern function's page. Added more external links that may prove useful to readers.
2026-08-28T21:15:46Z
Added Reference, External Links:  Added a reference to the Match Pattern function's page. Added more external links that may prove useful to readers.

				
				
				
				
				
				← Older revision
				Revision as of 21:15, 28 August 2026
				
Line 99:
Line 99:
\hmuch     # horizontal white space (a tab or space) followed by "much" \hmuch     # horizontal white space (a tab or space) followed by "much"
</syntaxhighlight>The reader should note that when the (?x) flag is in use, white space characters must be specified explicitly. e.g. <code>\s \h \v \t \r \n</code> etc. </syntaxhighlight>The reader should note that when the (?x) flag is in use, white space characters must be specified explicitly. e.g. <code>\s \h \v \t \r \n</code> etc.
*Unlike the expression syntax for the Match Pattern node, <code>\s</code> does not refer to a literal space character (ASCII 0x20). *Unlike the expression syntax for the [[Match Pattern function]], <code>\s</code> does not refer to a literal space character (ASCII 0x20).
:White space characters are represented as follows: :White space characters are represented as follows:
:{| class="wikitable" :{| class="wikitable"
Line 155:
Line 155:
* [https://regex101.com/ RegEx101] - A great resource for trying out your regular expression.  Contains help, syntax highlighting, etc.  '''Note''' LabVIEW uses PCRE, select this when using the website. * [https://regex101.com/ RegEx101] - A great resource for trying out your regular expression.  Contains help, syntax highlighting, etc.  '''Note''' LabVIEW uses PCRE, select this when using the website.
* [http://www.pcre.org Perl Compatible Regular Expressions (PCRE) website] - The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl 5. * [http://www.pcre.org Perl Compatible Regular Expressions (PCRE) website] - The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl 5.
* [https://www.pcre.org/original/doc/html/pcrepattern.html PCRE Pattern Manual Page] - Detailed, official documentation of PCRE pattern syntax
* [https://www.pcre.org/original/doc/html/pcresyntax.html PCRE Syntax Manual Page] - More abbreviated official documentation of PCRE pattern syntax
* [https://www.debuggex.com/cheatsheet/regex/pcre Debuggex PCRE Cheat Sheet] - A succinct reference for PCRE syntax



[[Category:String Palette]] [[Category:String Palette]]



MrJim: /* Tips and tricks */
2026-08-28T21:06:01Z
Tips and tricks

				
				
				
				
				
				← Older revision
				Revision as of 21:06, 28 August 2026
				
Line 100:
Line 100:
</syntaxhighlight>The reader should note that when the (?x) flag is in use, white space characters must be specified explicitly. e.g. <code>\s \h \v \t \r \n</code> etc. </syntaxhighlight>The reader should note that when the (?x) flag is in use, white space characters must be specified explicitly. e.g. <code>\s \h \v \t \r \n</code> etc.
*Unlike the expression syntax for the Match Pattern node, <code>\s</code> does not refer to a literal space character (ASCII 0x20). *Unlike the expression syntax for the Match Pattern node, <code>\s</code> does not refer to a literal space character (ASCII 0x20).
:White space characters are represented as follows: {| class="wikitable" |+ White Space Characters |- ! Escape !! ASCII Value !! Meaning |- | \t || 0x09 || Horizontal Tab (as from the tab key) |- | \n || 0x0A || Line Feed |- | || 0x0B || Vertical Tab (not commonly used) |- | \f || 0x0C|| Form Feed (not commonly used) |- | \r || 0x0D || Carriage Return |- | || 0x20 || Space (as from the space bar) |- |  \h || 0x20 0x09  || Space or Tab |- |  \v || 0x0A 0x0B 0x0C 0x0D  || Line Feed, Vertical Tab, Form Feed, Carriage Return |- |  \s || 0x09 0x0A 0x0B 0x0C 0x0D 0x20 || Union of characters included in \h and \v |} :White space characters are represented as follows:
:{| class="wikitable"
|+ White Space Characters
|-
! Escape !! ASCII Value !! Meaning
|-



| \t || 0x09 || Horizontal Tab (as from the tab key)
|-

| \n || 0x0A || Line Feed
|-

| || 0x0B || Vertical Tab (not commonly used)
|-

| \f || 0x0C|| Form Feed (not commonly used)
|-

| \r || 0x0D || Carriage Return
|-

| || 0x20 || Space (as from the space bar)
|-

|  \h || 0x20 0x09  || Space or Tab
|-

|  \v || 0x0A 0x0B 0x0C 0x0D  || Line Feed, Vertical Tab, Form Feed, Carriage Return
|-

|  \s || 0x09 0x0A 0x0B 0x0C 0x0D 0x20 || Union of characters included in \h and \v
|}
== XNode == == XNode ==
This node is an example of how [[XNode]]s are used as a primitive node in LabVIEW.  It utilizes the [[AdaptToInputs (XNode Ability)|AdaptToInputs]], [[Bounds (XNode Ability)|Bounds]], [[DisplayName (XNode Ability)|DisplayName]], [[GenerateCode (XNode Ability)|GenerateCode]], [[GrowInfo (XNode Ability)|GrowInfo]], [[Help (XNode Ability)|Help]], [[Image (XNode Ability)|Image]], [[Initialize (XNode Ability)|Initialize]], [[Size (XNode Ability)|Size]], [[Terms (XNode Ability)|Terms]], and [[UpdateStateWithRef (XNode Ability)|UpdateStateWithRef]] abilities.  The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode|XNodeWizardMode]] INI flag.  Many of the ability VIs are password protected. This node is an example of how [[XNode]]s are used as a primitive node in LabVIEW.  It utilizes the [[AdaptToInputs (XNode Ability)|AdaptToInputs]], [[Bounds (XNode Ability)|Bounds]], [[DisplayName (XNode Ability)|DisplayName]], [[GenerateCode (XNode Ability)|GenerateCode]], [[GrowInfo (XNode Ability)|GrowInfo]], [[Help (XNode Ability)|Help]], [[Image (XNode Ability)|Image]], [[Initialize (XNode Ability)|Initialize]], [[Size (XNode Ability)|Size]], [[Terms (XNode Ability)|Terms]], and [[UpdateStateWithRef (XNode Ability)|UpdateStateWithRef]] abilities.  The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode|XNodeWizardMode]] INI flag.  Many of the ability VIs are password protected.



MrJim: /* Tips and tricks */  Added explanation and table of white space escape sequences
2026-08-28T21:03:10Z
Tips and tricks:   Added explanation and table of white space escape sequences

				
				
				
				
				
				← Older revision
				Revision as of 21:03, 28 August 2026
				
Line 98:
Line 98:
s\w        # literal "s" followed by \w, which is an alphanumeric char or _ s\w        # literal "s" followed by \w, which is an alphanumeric char or _
\hmuch     # horizontal white space (a tab or space) followed by "much" \hmuch     # horizontal white space (a tab or space) followed by "much"
</syntaxhighlight>The read </syntaxhighlight>The reader should note that when the (?x) flag is in use, white space characters must be specified explicitly. e.g. <code>\s \h \v \t \r \n</code> etc.
*Unlike the expression syntax for the Match Pattern node, <code>\s</code> does not refer to a literal space character (ASCII 0x20).
:White space characters are represented as follows: {| class="wikitable" |+ White Space Characters |- ! Escape !! ASCII Value !! Meaning |- | \t || 0x09 || Horizontal Tab (as from the tab key) |- | \n || 0x0A || Line Feed |- | || 0x0B || Vertical Tab (not commonly used) |- | \f || 0x0C|| Form Feed (not commonly used) |- | \r || 0x0D || Carriage Return |- | || 0x20 || Space (as from the space bar) |- |  \h || 0x20 0x09  || Space or Tab |- |  \v || 0x0A 0x0B 0x0C 0x0D  || Line Feed, Vertical Tab, Form Feed, Carriage Return |- |  \s || 0x09 0x0A 0x0B 0x0C 0x0D 0x20 || Union of characters included in \h and \v |}
 
== XNode == == XNode ==
This node is an example of how [[XNode]]s are used as a primitive node in LabVIEW.  It utilizes the [[AdaptToInputs (XNode Ability)|AdaptToInputs]], [[Bounds (XNode Ability)|Bounds]], [[DisplayName (XNode Ability)|DisplayName]], [[GenerateCode (XNode Ability)|GenerateCode]], [[GrowInfo (XNode Ability)|GrowInfo]], [[Help (XNode Ability)|Help]], [[Image (XNode Ability)|Image]], [[Initialize (XNode Ability)|Initialize]], [[Size (XNode Ability)|Size]], [[Terms (XNode Ability)|Terms]], and [[UpdateStateWithRef (XNode Ability)|UpdateStateWithRef]] abilities.  The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode|XNodeWizardMode]] INI flag.  Many of the ability VIs are password protected. This node is an example of how [[XNode]]s are used as a primitive node in LabVIEW.  It utilizes the [[AdaptToInputs (XNode Ability)|AdaptToInputs]], [[Bounds (XNode Ability)|Bounds]], [[DisplayName (XNode Ability)|DisplayName]], [[GenerateCode (XNode Ability)|GenerateCode]], [[GrowInfo (XNode Ability)|GrowInfo]], [[Help (XNode Ability)|Help]], [[Image (XNode Ability)|Image]], [[Initialize (XNode Ability)|Initialize]], [[Size (XNode Ability)|Size]], [[Terms (XNode Ability)|Terms]], and [[UpdateStateWithRef (XNode Ability)|UpdateStateWithRef]] abilities.  The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode|XNodeWizardMode]] INI flag.  Many of the ability VIs are password protected.



MrJim: /* Tips and tricks */
2026-08-28T20:14:15Z
Tips and tricks

				
				
				
				
				
				← Older revision
				Revision as of 20:14, 28 August 2026
				
Line 90:
Line 90:
== Tips and tricks == == Tips and tricks ==
* Use back references to refer to previous partial matches in a regular expression. <code>\1</code> refers to the first partial match, <code>\2</code> to the second, and so on. For example, <code>(cat|dog) \1</code> matches "cat cat" or "dog dog" but not "cat dog" or "dog cat". * Use back references to refer to previous partial matches in a regular expression. <code>\1</code> refers to the first partial match, <code>\2</code> to the second, and so on. For example, <code>(cat|dog) \1</code> matches "cat cat" or "dog dog" but not "cat dog" or "dog cat".
  * Commenting regular expressions is encouraged for readability. There are two methods by which to accomplish this, both native to PCRE's syntax and not specific to LabVIEW.
*# Inline comments may be placed as in the following example: <code lang="perl">[A-Za-z\d]+(?#alphanumeric chars).+$</code> , where "alphanumeric chars" comprises the inline comment.
*# More readable comments may be included by enabling commenting via the <code>(?x)</code> flag. The flag must be specified at the very start of the regular expression: Doing so causes the PCRE compiler to ignore both horizontal and vertical white space as well as comments at the ends of lines that begin with <code>#</code>. For example: <syntaxhighlight lang="python">
(?x)       # Enable comments, ignore white space
I Lab      # The literal characters "I lab"
[WIEV]     # Any of {W, I, E, V}, case sensitive
s\w        # literal "s" followed by \w, which is an alphanumeric char or _
\hmuch     # horizontal white space (a tab or space) followed by "much"
</syntaxhighlight>The read
== XNode == == XNode ==
This node is an example of how [[XNode]]s are used as a primitive node in LabVIEW.  It utilizes the [[AdaptToInputs (XNode Ability)|AdaptToInputs]], [[Bounds (XNode Ability)|Bounds]], [[DisplayName (XNode Ability)|DisplayName]], [[GenerateCode (XNode Ability)|GenerateCode]], [[GrowInfo (XNode Ability)|GrowInfo]], [[Help (XNode Ability)|Help]], [[Image (XNode Ability)|Image]], [[Initialize (XNode Ability)|Initialize]], [[Size (XNode Ability)|Size]], [[Terms (XNode Ability)|Terms]], and [[UpdateStateWithRef (XNode Ability)|UpdateStateWithRef]] abilities.  The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode|XNodeWizardMode]] INI flag.  Many of the ability VIs are password protected. This node is an example of how [[XNode]]s are used as a primitive node in LabVIEW.  It utilizes the [[AdaptToInputs (XNode Ability)|AdaptToInputs]], [[Bounds (XNode Ability)|Bounds]], [[DisplayName (XNode Ability)|DisplayName]], [[GenerateCode (XNode Ability)|GenerateCode]], [[GrowInfo (XNode Ability)|GrowInfo]], [[Help (XNode Ability)|Help]], [[Image (XNode Ability)|Image]], [[Initialize (XNode Ability)|Initialize]], [[Size (XNode Ability)|Size]], [[Terms (XNode Ability)|Terms]], and [[UpdateStateWithRef (XNode Ability)|UpdateStateWithRef]] abilities.  The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode|XNodeWizardMode]] INI flag.  Many of the ability VIs are password protected.

← Older revision		Revision as of 23:19, 28 August 2026
Line 73:		Line 73:

	=== Details ===		=== Details ===
	'''Note''' The Match Regular Expression function does not support null characters in strings. If ~~you include null characters in~~ strings ~~you wire~~ to this function, LabVIEW returns an error and the function may return unexpected results.		*This function is used to match one or more substrings in '''input string''' by evaluating a '''regular expression''' against it, where the '''regular expression''' ("regex") follows the standardized syntax defined by the Perl Compatible Regular Expression (PCRE) specification.
			*Refer to the PCRE website at [http://www.pcre.org www.pcre.org] for more detailed information about Perl Compatible Regular Expressions.
			*From a cursory perspective, the Match Regular Expression node is functionally very similar to the [[Match Pattern function]], but is much more powerful, arguably more versatile, and provides many additional options.
			*The Match Regular Expression node executes much more slowly than the [[Match Pattern function]]. When executed relatively infrequently in an application, the difference is negligible, but when scaled and executed repeatedly, there is a noticeable performance penalty. Therefore, if the application does not require the power and complexity afforded by the Match Regular Expression function, the user may elect to use the [[Match Pattern function]] instead.
			*Regular expression support is provided by the PCRE library package. Refer to <National Instruments>\_Legal Information directory for more information about the license under which the PCRE library package is redistributed.
			'''Note''' The Match Regular Expression function does not support null characters (i.e. bytes with values of zero) in the input strings. If strings wired to this function include null characters, LabVIEW returns an error and the function may return unexpected results.

			====Grouping Patterns for Submatches====
			In straightforward use cases, the developer may simply rely on the value of the '''whole match''' terminal as the primary output of this function, as they would when using the [[Match Pattern function]]. For more complex use cases, multiple substrings from '''input string''' matching portions of the regular expression may be "captured," or returned separately from '''whole match''' as "submatches."

			When captured groups are specified within the regex, the entirety of the match is predictably returned as the value of '''whole match''', but smaller portions that are substrings of '''whole match''' are returned on separate output terminals.

			''<small>In official PCRE parlance, these submatches are referred to as "captured groups." In the LabVIEW documentation for this function, the outputs for these captured groups are referred to as both "substrings" and "submatches" inconsistently.</small>''

			The additional output terminals referred to as "'''Substring 1'''" .. "'''Substring n'''" are exposed by dragging the bottom of the function to expand it, similar to the behavior of the [[Scan From String function]]. These outputs are not depicted in the illustration at the top of this article.

			Within the '''regular expression''', the developer may specify that a portion of the match is to be captured and returned as a separate output by placing a subset of the regex within parentheses.

			For example:

			* Suppose <code>Hello LabVIEW!</code> is provided as the value of '''input string'''
			* Also suppose that <code>(el.)..(L..)</code> is provided as the value of '''regular expression''', wherein <code>.</code> may match any single character
			* Upon execution of the Match Regular Expression function, the value of the '''whole match''' terminal is set to <code>ello Lab</code>
			* '''Submatch 1''' then has a value of <code>ell</code>
			* '''Submatch 2''' then has a value of <code>Lab</code>

			If a captured group is nested within another captured group, the regular expression returns a submatch for the outer group before the inner group.

	*~~Regular expression support~~ is provided by the ~~PCRE library package. Refer to~~ <~~National Instruments~~>~~\_Legal Information directory for more information about the license under which the PCRE library package is redistributed~~.		For example:
	*Refer to the PCRE website at [http://www.~~pcre~~.~~org www~~.~~pcre~~.~~org] for more information about Perl Compatible Regular Expressions~~.
	*~~The~~ Match Regular Expression function ~~gives you more options for matching strings but performs more slowly than~~ the ~~[[Match Pattern function]].~~		* Suppose again that <code>Hello LabVIEW!</code> is provided as the value of '''input string'''
	*~~Use~~ regular ~~expressions (regex) in this function to refine searches~~.		* Also suppose that <code>(.(el.).).(L..)</code> is provided as the value of '''regular expression'''
			* Upon execution of the Match Regular Expression function, the value of the '''whole match''' terminal is set to <code>Hello Lab</code>
			* '''Submatch 1''' then has a value of <code>Hello</code>
			* '''Submatch 2''' has a value of <code>ell</code>
			* '''Submatch 3''' has a value of <code>Lab</code>

			In this example, '''Submatch 1''' is <code>Hello</code> because the regular expression matches the outer character group before the inner group.

	====Avoiding Stack Overflow====		====Avoiding Stack Overflow====
	Certain regular expressions that use repeated ~~grouped expressions~~ (such as (.\|\s)* or (a)) require ~~significant~~ resources to process when ~~applied to~~ large input strings~~. In some cases~~ a stack overflow ~~may occur on large input strings~~. ~~Some regular expressions~~ may ~~recurse repeatedly while attempting~~ to ~~match a large string, which may eventually overflow the stack~~. For example, the regular expression (.\|\n)A ~~and~~ a large input string may cause LabVIEW to crash. To avoid recursion, ~~you can rewrite~~ the regular expression (.\|\n)A as (?s).A. The (?s) ~~notation indicates that~~ a period ~~matches new lines~~. ~~You~~ also ~~can rewrite the expression~~ as [^A]A.		Certain regular expressions that use repeated capturing groups (such as <code>(.\|\s)</code> or <code>(a)</code> ) require substantial resources to process when evaluated over large input strings, potentially leading to a stack overflow. Expressions involving captured groups that may cause excessive recursion are to be avoided for this reason. For example, evaluating the regular expression <code>(.\|\n)A</code> over a large input string may cause LabVIEW to crash. To avoid recursion, the regular expression <code>(.\|\n)A</code> may be rewritten as <code>(?s).A</code>. The <code>(?s)</code> flag placed at the start of the regular expression instructs the compiler to include vertical white space characters when matching against the metacharacter, <code>.</code> (a period character in an expression). <code>(.\|\n)A</code> may also be rewritten as <code>[^A]A</code>, which perhaps unintuitively includes vertical white space when matching characters other than "A" that precede "A".

	~~====Grouping Patterns for Submatches====~~		As a general best practice, the developer may also wish to limit the allowable length of the input string to be evaluated by the regular expression.
	~~You can capture submatches by placing parentheses ( ) around~~ a ~~portion of a regular expression that you want~~ the ~~function~~ to ~~return as a submatch. For example,~~ the ~~regular expression (el.)..(L..) returns two submatches in~~ the input string ~~Hello LabVIEW!: ell and Lab. Each submatch corresponds~~ to ~~a character group in the order that the character group appears in~~ the regular expression~~. In this example, '''submatch 1''' is ell and '''submatch 2''' is Lab~~.

	~~If you nest~~ a ~~character~~ group ~~within another character~~ group, ~~the regular expression creates~~ a ~~submatch for the outer~~ group ~~before~~ the ~~inner group~~. For example, ~~the regular expression (.~~(~~el.~~)~~.).(L..) returns three submatches in~~ the ~~input Hello LabVIEW!: Hello, ell,~~ and ~~Lab. In this example~~, ~~'''submatch 1''' is Hello because~~ the ~~regular expression matches~~ the ~~outer character group before the inner group~~.		It should also be noted that characters or expressions that form a group need not be ''captured'' as a submatch. To group characters as part of an expression without capturing them as output, they may form a non-capturing group. The syntactical difference is that a non-capturing group includes <code>?:</code> after the opening <code>(</code>. For example, while <code>(ABC)</code> matches the string "ABC" and includes it as a submatch, <code>(?:ABC)</code> likewise groups the characters "ABC" together but does not return them as the value of a substring output.

	== Tips and tricks ==		== Tips and tricks ==

← Older revision		Revision as of 21:15, 28 August 2026
Line 99:		Line 99:
	\hmuch # horizontal white space (a tab or space) followed by "much"		\hmuch # horizontal white space (a tab or space) followed by "much"
	</syntaxhighlight>The reader should note that when the (?x) flag is in use, white space characters must be specified explicitly. e.g. <code>\s \h \v \t \r \n</code> etc.		</syntaxhighlight>The reader should note that when the (?x) flag is in use, white space characters must be specified explicitly. e.g. <code>\s \h \v \t \r \n</code> etc.
	*Unlike the expression syntax for the Match Pattern ~~node~~, <code>\s</code> does not refer to a literal space character (ASCII 0x20).		*Unlike the expression syntax for the [[Match Pattern function]], <code>\s</code> does not refer to a literal space character (ASCII 0x20).
	:White space characters are represented as follows:		:White space characters are represented as follows:
	:{\| class="wikitable"		:{\| class="wikitable"
Line 155:		Line 155:
	* [https://regex101.com/ RegEx101] - A great resource for trying out your regular expression. Contains help, syntax highlighting, etc. '''Note''' LabVIEW uses PCRE, select this when using the website.		* [https://regex101.com/ RegEx101] - A great resource for trying out your regular expression. Contains help, syntax highlighting, etc. '''Note''' LabVIEW uses PCRE, select this when using the website.
	* [http://www.pcre.org Perl Compatible Regular Expressions (PCRE) website] - The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl 5.		* [http://www.pcre.org Perl Compatible Regular Expressions (PCRE) website] - The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl 5.
			* [https://www.pcre.org/original/doc/html/pcrepattern.html PCRE Pattern Manual Page] - Detailed, official documentation of PCRE pattern syntax
			* [https://www.pcre.org/original/doc/html/pcresyntax.html PCRE Syntax Manual Page] - More abbreviated official documentation of PCRE pattern syntax
			* [https://www.debuggex.com/cheatsheet/regex/pcre Debuggex PCRE Cheat Sheet] - A succinct reference for PCRE syntax

	[[Category:String Palette]]		[[Category:String Palette]]

← Older revision		Revision as of 21:03, 28 August 2026
Line 98:		Line 98:
	s\w # literal "s" followed by \w, which is an alphanumeric char or _		s\w # literal "s" followed by \w, which is an alphanumeric char or _
	\hmuch # horizontal white space (a tab or space) followed by "much"		\hmuch # horizontal white space (a tab or space) followed by "much"
	</syntaxhighlight>The ~~read~~		</syntaxhighlight>The reader should note that when the (?x) flag is in use, white space characters must be specified explicitly. e.g. <code>\s \h \v \t \r \n</code> etc.
			*Unlike the expression syntax for the Match Pattern node, <code>\s</code> does not refer to a literal space character (ASCII 0x20).
			:White space characters are represented as follows: {\| class="wikitable" \|+ White Space Characters \|- ! Escape !! ASCII Value !! Meaning \|- \| \t \|\| 0x09 \|\| Horizontal Tab (as from the tab key) \|- \| \n \|\| 0x0A \|\| Line Feed \|- \| \|\| 0x0B \|\| Vertical Tab (not commonly used) \|- \| \f \|\| 0x0C\|\| Form Feed (not commonly used) \|- \| \r \|\| 0x0D \|\| Carriage Return \|- \| \|\| 0x20 \|\| Space (as from the space bar) \|- \| \h \|\| 0x20 0x09 \|\| Space or Tab \|- \| \v \|\| 0x0A 0x0B 0x0C 0x0D \|\| Line Feed, Vertical Tab, Form Feed, Carriage Return \|- \| \s \|\| 0x09 0x0A 0x0B 0x0C 0x0D 0x20 \|\| Union of characters included in \h and \v \|}

	== XNode ==		== XNode ==
	This node is an example of how [[XNode]]s are used as a primitive node in LabVIEW. It utilizes the [[AdaptToInputs (XNode Ability)\|AdaptToInputs]], [[Bounds (XNode Ability)\|Bounds]], [[DisplayName (XNode Ability)\|DisplayName]], [[GenerateCode (XNode Ability)\|GenerateCode]], [[GrowInfo (XNode Ability)\|GrowInfo]], [[Help (XNode Ability)\|Help]], [[Image (XNode Ability)\|Image]], [[Initialize (XNode Ability)\|Initialize]], [[Size (XNode Ability)\|Size]], [[Terms (XNode Ability)\|Terms]], and [[UpdateStateWithRef (XNode Ability)\|UpdateStateWithRef]] abilities. The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode\|XNodeWizardMode]] INI flag. Many of the ability VIs are password protected.		This node is an example of how [[XNode]]s are used as a primitive node in LabVIEW. It utilizes the [[AdaptToInputs (XNode Ability)\|AdaptToInputs]], [[Bounds (XNode Ability)\|Bounds]], [[DisplayName (XNode Ability)\|DisplayName]], [[GenerateCode (XNode Ability)\|GenerateCode]], [[GrowInfo (XNode Ability)\|GrowInfo]], [[Help (XNode Ability)\|Help]], [[Image (XNode Ability)\|Image]], [[Initialize (XNode Ability)\|Initialize]], [[Size (XNode Ability)\|Size]], [[Terms (XNode Ability)\|Terms]], and [[UpdateStateWithRef (XNode Ability)\|UpdateStateWithRef]] abilities. The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode\|XNodeWizardMode]] INI flag. Many of the ability VIs are password protected.

← Older revision		Revision as of 20:14, 28 August 2026
Line 90:		Line 90:
	== Tips and tricks ==		== Tips and tricks ==
	* Use back references to refer to previous partial matches in a regular expression. <code>\1</code> refers to the first partial match, <code>\2</code> to the second, and so on. For example, <code>(cat\|dog) \1</code> matches "cat cat" or "dog dog" but not "cat dog" or "dog cat".		* Use back references to refer to previous partial matches in a regular expression. <code>\1</code> refers to the first partial match, <code>\2</code> to the second, and so on. For example, <code>(cat\|dog) \1</code> matches "cat cat" or "dog dog" but not "cat dog" or "dog cat".
			* Commenting regular expressions is encouraged for readability. There are two methods by which to accomplish this, both native to PCRE's syntax and not specific to LabVIEW.
			*# Inline comments may be placed as in the following example: <code lang="perl">[A-Za-z\d]+(?#alphanumeric chars).+$</code> , where "alphanumeric chars" comprises the inline comment.
			*# More readable comments may be included by enabling commenting via the <code>(?x)</code> flag. The flag must be specified at the very start of the regular expression: Doing so causes the PCRE compiler to ignore both horizontal and vertical white space as well as comments at the ends of lines that begin with <code>#</code>. For example: <syntaxhighlight lang="python">
			(?x) # Enable comments, ignore white space
			I Lab # The literal characters "I lab"
			[WIEV] # Any of {W, I, E, V}, case sensitive
			s\w # literal "s" followed by \w, which is an alphanumeric char or _
			\hmuch # horizontal white space (a tab or space) followed by "much"
			</syntaxhighlight>The read
	== XNode ==		== XNode ==
	This node is an example of how [[XNode]]s are used as a primitive node in LabVIEW. It utilizes the [[AdaptToInputs (XNode Ability)\|AdaptToInputs]], [[Bounds (XNode Ability)\|Bounds]], [[DisplayName (XNode Ability)\|DisplayName]], [[GenerateCode (XNode Ability)\|GenerateCode]], [[GrowInfo (XNode Ability)\|GrowInfo]], [[Help (XNode Ability)\|Help]], [[Image (XNode Ability)\|Image]], [[Initialize (XNode Ability)\|Initialize]], [[Size (XNode Ability)\|Size]], [[Terms (XNode Ability)\|Terms]], and [[UpdateStateWithRef (XNode Ability)\|UpdateStateWithRef]] abilities. The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode\|XNodeWizardMode]] INI flag. Many of the ability VIs are password protected.		This node is an example of how [[XNode]]s are used as a primitive node in LabVIEW. It utilizes the [[AdaptToInputs (XNode Ability)\|AdaptToInputs]], [[Bounds (XNode Ability)\|Bounds]], [[DisplayName (XNode Ability)\|DisplayName]], [[GenerateCode (XNode Ability)\|GenerateCode]], [[GrowInfo (XNode Ability)\|GrowInfo]], [[Help (XNode Ability)\|Help]], [[Image (XNode Ability)\|Image]], [[Initialize (XNode Ability)\|Initialize]], [[Size (XNode Ability)\|Size]], [[Terms (XNode Ability)\|Terms]], and [[UpdateStateWithRef (XNode Ability)\|UpdateStateWithRef]] abilities. The abilities used can be viewed after enabling the [[LabVIEW configuration file/Miscellaneous#XNodeWizardMode\|XNodeWizardMode]] INI flag. Many of the ability VIs are password protected.