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

  • UI & Usability
28 Comments
Active Participant Jarrod_S.
Active Participant

I would worry about a few things, which may or may not be founded:

 

1. Does this mean all my class methods would need their front panels to be loaded into memory when executed as subVIs? I would kind of doubt VIs with XControls can have their front panels stripped, but I could be wrong.

2. Would this have any implication for using classes on RT?

3. Is there any execution overhead of using XControls instead of regular controls as connector pane terminals? Does the XControl run any additional code when the value is set for the subVI?

Trusted Enthusiast Trusted Enthusiast
Trusted Enthusiast

XContorl overhead depends on how it's programmed.

 

Just don't update too often otherwise you'll get a backlog of data change Events and eventually the event order gets all mixed up - it's not a pretty s....

Trusted Enthusiast
Trusted Enthusiast

> Does this mean all my class methods would need their front

> panels to be loaded into memory when executed as subVIs?

> I would kind of doubt VIs with XControls can have their front

> panels stripped, but I could be wrong.

 

A) You're worried that the XControl would cause the class methods to keep FPs in memory. Class methods would be the ones that *don't* use the XControl. It would be all the other VIs that use the class that would host the XControl. 

B) Hosting an XControl does not cause your FP to be in memory. The facade VI of an XControl only executes when the FP is loaded for other reasons -- it is not itself a reason for loading. (Note that this is why it is a bad idea to have an XControl that modifies its own Value property ... such code only runs when the FP is open.)

C) Thus it is perfectly legit to strip FPs of VIs even if those VIs host XControls. 

Member _Y_
Member

Such a feature is highly desirable. However, there is a question (bottleneck?):

* Objects can be assembled in arrays (a powerful feature of OOP).

* XContriols cannot be assembled in arrays (a sad reality). 

Member kegghead
Member
I'm curious how inheritance be handled? Would a child class that only slightly extends the base class essentially have to redefine and reimplement the entire facade?
Member PaulLotz
Member

AQ,

 

Thanks for addressing my question above.

 

I have a new question: Will the new default XControl give the developer access to the class type, then?  (Yes, I'm thinking about XML as an example).  If so, then I am all for it.

Trusted Enthusiast Trusted Enthusiast
Trusted Enthusiast

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

 

You can always right click and select a custom probe (perhaps the generic) if one wants to so no need for that (LabVIEW currently remembers what kind of probe is used for a specific datatype)

 

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

 

Why? An XControl is a GUI element in itself? If the XControl developer wants to suport multiple styles of the XControl it should be part of the specific XControl api.

If a developer is on a flow he should be able to check the actual default style for an owning VI.

 

Ton

Proven Zealot
Proven Zealot
A very good ask...Kudos.
Trusted Enthusiast
Trusted Enthusiast

> I have a new question: Will the new default XControl give the developer access to

> the class type, then?  (Yes, I'm thinking about XML as an example).  If so, then I am all for it.

 

Not unless the author of the class gives the XControl access (i.e. by friending the XControl). 

Member PaulLotz
Member

>> I have a new question: Will the new default XControl give the developer access to

>> the class type, then?  (Yes, I'm thinking about XML as an example).  If so, then I am all for it.

 

>Not unless the author of the class gives the XControl access (i.e. by friending the XControl). 

 

Hmm... as long as it's possible.  Then I think this has real potential for the type of application I am considering.  (Of course, I'd really encourage NI to think along these lines.  I think this has major implications for OO usage.)  This has my vote now.