LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
AristosQueue (NI)

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

Status: New

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

Jarrod S.
National Instruments
Intaris
Proven Zealot

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

AristosQueue (NI)
NI Employee (retired)

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

_Y_
Active Participant
Active Participant

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

_____________________________________
www.azinterface.net - Interface-based multiple inheritance for LabVIEW OOP
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?
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.

TCPlomp
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

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
muks
Proven Zealot
A very good ask...Kudos.
AristosQueue (NI)
NI Employee (retired)

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

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.