Tag an XControl as the default control/indicator for a LabVIEW class

[AristosQueue (NI)]

LabVIEW classes are how you create new data types in LabVIEW. But part of being a new LV data type is having a front panel representation. Although users can write XControls for displaying their classes, and they can put those XControls in the palettes, whenever a user of their class chooses "Create Control" or "Create Indicator" for the LabVIEW class terminal, they get the cube display. In order to really add a new data type to LabVIEW that behaves as well as, for example, the Timestampp or the Waveform, there needs to be some way to associate a class with an XControl and say, "This particular XControl should be used as this class' default control/indicator whenever one needs to be built."  (To prevent infinite recursion and load dependency problems, whenever you did Create Control/Indicator on a member VI of the class, users would still get the cube control/indicator.)

[GregSands]

Just stumbled across this again as I was searching before posting a related idea.  So instead of a new idea, a few questions on this one:

1. Any progress on this in the last 5 years?
   
   
2. One issue with XControls is that the data created in a control or indicator is not a Typedef (even if XControlData.ctl is).  If XControls gain the ability to have a class datatype, would adding proper Type Definitions to XControls be a easy additional outcome?  I think this idea is related - interchange "custom control" and "typedef" and "class".
   
   
3. Now to my original thought - is there a way to make this idea work on the Block Diagram, i.e. to define a Class Constant? Perhaps a Class border (similar to a Cluster border) surrounding the Class data?  At the moment, an XControl's Constant is just the raw data, with no indication that it is defined from an XControl.

[AristosQueue (NI)]

>  If XControls gain the ability to have a class datatype

XControls already have the ability to have a class data type -- and they have had this ability since the inception of LabVIEW classes. The aim of this idea is to make it so that when you drop a class from the project or do "create control" on a terminal that you get the XControl, if that VI is not a member of the class then you get the XControl instead of the cube.

There has been no progress on this in 5 years. It keeps getting deprioritized.

> would adding proper Type Definitions to XControls be a easy additional outcome

No. That lack on the part of XControls is very deep seated and unfortunate, and nothing this idea will improve it. When it was attempted, we discovered that we would need to totally scrap XControls and build a very different architecture in order to enable XControls to use a typedef'd type.

> is there a way to make this idea work on the Block Diagram, i.e. to define a Class Constant?

As soon as XControls can be dropped on the block diagram, yes. But until then, no. I have often wished to have a diagram constant for a class that was interactive. XControls are front panel entities only.

[Intaris]

No. That lack on the part of XControls is very deep seated and unfortunate, and nothing this idea will improve it. When it was attempted, we discovered that we would need to totally scrap XControls and build a very different architecture in order to enable XControls to use a typedef'd type.

Well if this scrapping IS ever on the board, there are a few other things I'd like to have "fixed" about XControls.....

[AristosQueue (NI)]

> Well if this scrapping IS ever on the board, there are a few other things I'd like to have "fixed" about XControls.....

Join the club. 🙂 XControls are great, but so limited compared to where they could be. I have great dreams for them.

[GregSands]

Maybe we need an idea to rewrite XControls, just to see what the level of support is.  I know for me that every time I finish writing one, I remember why I'd decided never to use them ever again!

Spoiler

In fact I've written and use 10x as many XNodes as XControls, and with far less hassle...

[AristosQueue (NI)]

> In fact I've written and use 10x as many XNodes as XControls, and with far less hassle...

Which is particularly ironic since those two share 90% of their code. The issues are all with the live graphics aspects of controls... that's where the banes crop up.

[Intaris]

and those banes are nasty.....

Maybe NI should have released XNodes and kept XControls secret?

[Mads]

I ended up in this thread as I was thinking about posting an idea for a "dynamic dispatch" control...The point would be that in all cases where the type of control you want to display to the user depends on choices made elsewhere (for example if the user selects a certain instrument type in a drop-down menu we want to show him the configurations available for that instrument in below the drop-down menu), we could have a front panel equivalent of dynamic dispatching (instead of having all the overhead of using subpanes and/or create XControls to achieve enough dynamics).  

While toying with the idea I considered calling the idea "LabVIEW Objects with user interface".  This sounds a bit like this old and rejected idea about showing the object cluster on the front panel, but it would be different as this would really be a separate part of the object definition (much like the XControl's facade). The point would be that it might only provide access to some parts of the data (make some of it public, keeping others private) - and you could even define multiple facade's to provide access to different data and/or have different user interface designs.  (Perhaps this is different enough already from this XControl-association idea and I should post it as a new idea!). With inheritance you could change the user interface easily based on the user's choices just by creating the right object...*

* In the case where each related object has more than one facade this might cause a problem - but that could be solved by having a right-click option on the parent class front panel control to set the default facade for4 the different children...So a child object might have a default facade which is the one you would get in your user interface by default should that child class be loaded  (in the parent facade if you want), but you would then have the ability to change that locally to whatever you prefer (here we could even provide a nice preview feature during the operation...).

However - I had concluded that I did *not* want to call it "LabVIEW objects with user interface" after all - , because the core of the idea does not really dictate such an implementation. This could instead be a new type of control (and/or replace the  oldXControl yes) - or something else completely; it would be the equivalent of a front panel only type of class you could say (unlike with XControls it might only be a facade, no logic), but the concept would not necessarily have to be linked to LVOOP or XControls at all...