Jump to content

XControl: Difference between revisions

From LabVIEW Wiki
mNo edit summary
 
(7 intermediate revisions by 4 users not shown)
Line 1: Line 1:
__NOTOC__
{{TOCright}}'''XControls''' were first introduced in [[LabVIEW 8]] and enhance the power of front panel objects. An XControl is a front panel object with a dedicated UI logic code linked and encapsulated in the XControl in order to react to user events on the controls it contains. An XControl consists of several parts, managed in a [[XCTL File Extension |''.xctl'']] file. The ''.xctl'' file is a XML file like similar to [[LabVIEW Project]] or [[LabVIEW Project Library]] files.  
{| align="right" border="0"
|__TOC__
|-
|}
==Introduction==
XControls are introduced in LabVIEW 8.0 and enhance the power of front panel objects in great ways.


Essentially an XControl is a front panel object with dedicated code linked in to react on certain user events.
Other parts of the XControl are called:
*[[XControl:Properties|Properties]]
*[[XControl:Abilities|Abilities]]
*[[XControl:Methods|Methods]]


An XControl exists of several parts, managed in a .xctl file. The .xctl file is a XML-file like the project-file. Other parts of the XControl are abilities.
==[[XControl:Abilities|Abilities]]==


==[[XControl:Properties|Properties]]==


==[[XControl:Methods|Methods]]==
== Limitations ==
An XControl functions like a subpanel in the hosting VI. [[Subpanel]]s (and therefore XControls) ''can not'' be placed inside an array. Note that you ''can'' define your XControl data as an array of any LabVIEW data type, and you ''can'' use array controls in the facade vi.


==Caveats/Limitations==
Using LabVIEW native objects (.lvclass files) inside the state control of an XControl tends to crash LabVIEW for versions less than 8.5.1 when the XControl is used in a different application instance.
===Limitations===
An XControl functions like a subpanel in the hosting VI. Subpanels (and therefore XControls) ''can not'' be placed inside an array. Note that you ''can'' define your XControl data as an array of any LabVIEW data type, and you ''can'' use array controls in the facade vi.


Using LabVIEW native objects (.lvclass files) inside the state control of an XControl tends to crash LabVIEW for versions less than 8.5.1 when the XControl is used in a different application instance.
Also, XControls have limitations when running in VIs that are part of a [[LabVIEW Project Library]] (or [[Packed Project Library|Packed Project Library (PPL)]]), or a [[LabVIEW Class]]. This makes it difficult to use in a large application using [[Actor Framework]] or plugin architectures using [[Packed Project Library|PPLs]].  See more in the [[QControl|QControls]] article.


===Tricks===
== Tricks ==
* If you require a variable number of runtime instances of your XControl, Jarrod Slocum of [[National Instruments]] has created an example [http://community.ni.com/examples/linked-object-list-in-labview-8-0-using-xcontrols Linked Object List] based on a Subpanel ''inside'' an XControl.
*If you require a variable number of runtime instances of your XControl, Jarrod Slocum of [[National Instruments]] has created an example [http://community.ni.com/examples/linked-object-list-in-labview-8-0-using-xcontrols Linked Object List] based on a Subpanel ''inside'' an XControl.


* If you want to react to dynamic events (or user events) you need them to register at the XControl Facade '''before''' the event happens.
* If you want to react to dynamic events (or user events) you need them to register at the XControl Facade '''before''' the event happens.
* If Façade is not executing fast enough to keep up with data updates, it causes the updates to queue up. The updates will happen even after the VI stops running. To reduce data updates:
: (Thanks to Ram Kudukoli (of NI R&D) for sharing this with us at the recent CLA Summit)
:* Open the Xcontrol .xctl file in a text editor like Notepad.
:* Add the bolded line shown below:
<Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property>
<Property Name="NI.XClass.Flags" Type="Int">0</Property>
'''<Property Name="NI.XCtl.OptimizeDataUpdate" Type="Bool">true</Property>
<Property Name="NI.XItem.DeclaredLeakProof" Type="Bool">false</Property>'''
:* Save the .xctl file.
([http://lavag.org/topic/15680-no-update-on-x-control-value-change/page__view__findpost__p__94838 LAVAG source])
== See also ==
*[[QControl|QControls]]
[[Category:XControl]]
[[Category:XControl]]

Latest revision as of 15:58, 9 June 2020

XControls were first introduced in LabVIEW 8 and enhance the power of front panel objects. An XControl is a front panel object with a dedicated UI logic code linked and encapsulated in the XControl in order to react to user events on the controls it contains. An XControl consists of several parts, managed in a .xctl file. The .xctl file is a XML file like similar to LabVIEW Project or LabVIEW Project Library files.

Other parts of the XControl are called:


Limitations

An XControl functions like a subpanel in the hosting VI. Subpanels (and therefore XControls) can not be placed inside an array. Note that you can define your XControl data as an array of any LabVIEW data type, and you can use array controls in the facade vi.

Using LabVIEW native objects (.lvclass files) inside the state control of an XControl tends to crash LabVIEW for versions less than 8.5.1 when the XControl is used in a different application instance.

Also, XControls have limitations when running in VIs that are part of a LabVIEW Project Library (or Packed Project Library (PPL)), or a LabVIEW Class. This makes it difficult to use in a large application using Actor Framework or plugin architectures using PPLs. See more in the QControls article.

Tricks

  • If you require a variable number of runtime instances of your XControl, Jarrod Slocum of National Instruments has created an example Linked Object List based on a Subpanel inside an XControl.
  • If you want to react to dynamic events (or user events) you need them to register at the XControl Facade before the event happens.
  • If Façade is not executing fast enough to keep up with data updates, it causes the updates to queue up. The updates will happen even after the VI stops running. To reduce data updates:
(Thanks to Ram Kudukoli (of NI R&D) for sharing this with us at the recent CLA Summit)
  • Open the Xcontrol .xctl file in a text editor like Notepad.
  • Add the bolded line shown below:
<Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property>
<Property Name="NI.XClass.Flags" Type="Int">0</Property>
<Property Name="NI.XCtl.OptimizeDataUpdate" Type="Bool">true</Property>
<Property Name="NI.XItem.DeclaredLeakProof" Type="Bool">false</Property>
  • Save the .xctl file.

(LAVAG source)

See also