LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

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

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.)

28 Comments
Active Participant

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.

 

Proven Zealot

>  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.

 

Trusted Enthusiast

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.....

Proven Zealot

> 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.

Active Participant

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...
Proven Zealot

> 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.

Trusted Enthusiast

and those banes are nasty.....

 

Maybe NI should have released XNodes and kept XControls secret?

Active Participant

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...

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.