A chance to give back to AQ

[Mark Balla]

If you have ever given Aristos Queue a Kudo or been helped by one of his post then here is your chance to give back.

In his presentation Wednesday at NI Week he asked that everyone go to the Idea Exchange and vote for

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

All you need to do is click on the link, logon and then click on the star in the upper left corner

Here is the discription

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.

I also like this Idea. The main reason that I have avoided classes in the past is because I couldn't see the class data values passing in and out of a class vi.

While you are in the Idea exchange checkout all the other Ideas and vote for your favorites.

NI is going to use this site to help determine future functions of LabVIEW.

[jgcode]

If you have ever given Aristos Queue a Kudo or been helped by one of his post then here is your chance to give back.

Happily done.

[Daklu]

Questions:

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

I voted for the idea in spite of my questions; I trust AQ to take LVOOP in the right direction.

[PaulL]

Actually, I'm hoping for some clarification on this one.

AQ is right almost all the time, so I pay a good deal of attention to his suggestions.

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

Paul

[Mark Yedinak]

Questions:

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?
   

The X-Control could be listed as a friend of the class and therefore have visibility to the private data. Actually NI did a nice thing by creating a community declaration for class methods. In traditional OO a friend of the class would have access to all private methods. NI created the concept of a community method. Private methods remain private to the class. Community methods are visible by friends of the class as well as class members. And of course public methods are visible to all.

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

I voted for the idea in spite of my questions; I trust AQ to take LVOOP in the right direction.

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.

Actually, I'm hoping for some clarification on this one.

AQ is right almost all the time, so I pay a good deal of attention to his suggestions.

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

Paul

Based on the presentation at NI Week when this topic came up I believe that the push is to make the X-Control the default. However you would still have teh option of using the cube.

[crelf]

In his presentation Wednesday at NI Week he asked that everyone go to the Idea Exchange and vote for Tag an XControl as the default control/indicator for a LabVIEW class

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

AQ is right almost all the time...

*almost*?!?

[shoneill]

*almost*?!?

Yup.

Here.

The day I read that thread, I believe I may have cried. AQ is fallible.

Shane.

[shoneill]

Yup.

Here.

The day I read that thread, I believe I may have cried. AQ is fallible.

Shane.

Since Ireland just introduced new blasphemy laws, do I have to start worrying about my last post?

-looks over shoulder-

Shane.

[jgcode]

[cross posted to ni.com]

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?

Edited August 15, 2009 by jgcode

[Aristos Queue]

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.

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.

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.

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.

[Aristos Queue]

Please post all further comments on the forum for the idea itself... that way this conversation stays all in one place.

[crelf]

Topic closed - continue the discussion here.