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

[Intaris]

Good idea.

But if the XControl is a member of the class and uses even one VI of the class, doesn't this result in the XControl locking the Class locking the Xcontrol locking......?

Message Edited by Intaris on 07-01-2009 01:44 PM

[AristosQueue (NI)]

The XControl wouldn't be a member of the class. The class would have a reference to the XControl, not ownership of it.

[Intaris]

Aah, OK.

[drval]

I agree with AQ on this...great idea!

[gb119]

Although solving the problem of how to allow XControls to be members of classes without locking everyting up would give much the nicest way of ensuring that the default control was available. Would also make it obvious how to make an XControl into the default control - jsut like setting the default palette, have a drop down list on a property page that lists all XControls that are members of the class that have the correct type to match the class. Somewhat like setting the default probe (another usage case where having a default control would be really handy).

[crelf]

This is a really important attribute for the new errors class to work.

[Mark_Yedinak]

While this should be the default it would be useful in some cases to allow the current cube to be used as the front panel control.

[jgcode]

[cross posted to LAVA] 

Is this related to how the new plots are implemented in 2009?
Are the FP Objects here, associated with a default class (or in this case an array of classes)?
Or is this totally different?

Message Edited by jg-code on 08-14-2009 08:48 PM

[AristosQueue (NI)]

jg-code: Totally different. The plots are using LV classes, but their FP terminals are still numeric types. This is about creating XControls whose FP Terminal type is a given LV class and then marking that class to say "when a control/indicator needs to be created for this class, use this XControl."

[AristosQueue (NI)]

I made some comments on LAVA that I want to record here also. The text in italics is from LAVA users. 

Daklu, on 08 August 2009 - 11:57 PM, said:

1. What happens if the class can't find the xcontrol? Is the class broken? Or, since the xcontrol is essentially a window into the class data, does the fp representation default to the cube? If that's the case, considering that the xcontrol isn't a class member, doesn't it violate the classes private data?

Mark Yedinak answered this part succintly in his post above regarding friendship and community scope. The class would not be broken if the XControl was missing. This is an editor only feature and we wouldn't want it to affect the run-time behavior of the class itself. This is merely an annotation on the class that says "when the user is creating a control/indicator of this class, if that ctrl/indicator is not on a member VI of this class nor of any subVI used by the class then the new control/indicator should be of this particular XControl instead of the cube."

2. Is the intended use case for the class designer to implement and deploy xcontrols with the class or to leave that to the class users?

The intended use case is for this to be something that the designer of the class creates. Thus if I create the Timestamp.lvclass, I could go ahead and create Timestamp.xctl which implements the calendar FP control. That way when users of my class are working, they don't see a class, they see a native LV data type with all the bells and whistles that everyone expects from a LV built-in data type.

Users of the class can already create an XControl for any given class that they want. What's missing is the hook into the LV editor for that XControl to be the default display for the class whenever LV needs to automatically create a display for the data. Currently LV uses the cube whenever it automatically creates one.

Paul_at_Lowell, on 11 August 2009 - 01:18 PM, said:

I'm skeptical of the above description, though. I like that on a subVI the class control and indicator are cubes or boxes. This is one advantage over using large clusters. (Something like visual encapsulation, maybe?)
Of course it would be good to have a way to display the contents of an object easily on a UI, and I can see how XControls are well-suited for this task. I just want to ensure I can still use the box control or indicator on the front panel (or the block diagram as a constant).

I'm sure we would encode some way to explicitly drop the cube, but the use case this is intended to handle is one where such an option would rarely/never be desirable. Suppose I use "Create SubVI From Selection" to create a subVI with a timestamp input. Would you want an opaque cube to show up instead of the calendar display? Almost certainly not. LV users are used to being able to see the values of their data on the FP in every subVI. Is there runtime overhead associated with this? Only if the FP is loaded. As long as the FP is not loaded into memory* then the XControl doesn't get updates and its code never runs, so it doesn't get in the way of fast subVI execution. You suggest that for hiding large clusters, this might be useful. A) For a class where you're not interested in seeing the private data, don't create any default XControl. 🙂 or B) You can always create a small XControl that only displays a small portion of the relevant data, or is perhaps growable/shrinkable to crunch down to small form.

* FP is not loaded as long as window not open, no open ctrl/vi refs, no use of local variables or statically bound property/invoke nodes.

Mark Yedinak, on 11 August 2009 - 01:56 PM, said:

This is a good question and if nothing else the user of the class should have the ability to override the X-Control with their own version.

I agree. It should be as easy as "Create new child class. Create XControl for child class. Set the XControl as the default for the child class. Change nothing else about the child class." It now has the exact same behavior as the parent but with a new display.

jgcode, on 14 August 2009 - 08:44 PM, said:

Is this related to how the new plots are implemented in 2009?
Are the FP Objects here, associated with a default class (or in this case an array of classes)?
Or is this totally different?

No, this is not related. The new plots all have LV built-in data types -- numerics, waveforms, arrays, etc. This is for creating displays for the class data types that users create. The new plots do use classes as part of their implementation, but their data type (the type of the FP terminal itself) is not a class type.

A couple more notes:
1. There probably needs to be an option for "should this XControl be used when probing this class or should the generic probe continue to be used"
2. See VI Properties dialog, Editor Options page. This page allows you to set which type of control to create on the FP when doing Create Control or Create Indicator. This feature would probably need to allow users to set different XControls for modern, classic and system displays.