OOP : class object private data as main VI front panel control?

[markrz]

Is it possible for an object's private data (e.g. Class.ctl) to appear as a main VI front panel control so that the object can take care of user input without help from the main VI? Or is it better to store some data separate from the object and use a reference, and have the main VI tell the object when there is user input, e.g. in the main VI event loop?

Thanks, Mark

[Thoric]

A class's private data is entirely private, and cannot be placed as a front panel control. Access to the content has to be made through data member access VIs. That's why there's a wizard for creating these access VIs - because they're usually numerous and that would be tedious to create by hand.

If you have data that is user-configurable (editable from a main VI's front panel), is there a problem with passing that data into the class's private data using the event structure you describe? Is there a specific reason you want the data 'outside' of the class?

[markrz]

Hi Thoric,

  thanks very much for your reply!

I was hoping that the object could be entirely self contained. In this project, the class is data acquisition instrument, and the user needs to change scales, settings, etc. If the object could take care of these instrument settings on its own, both recording them and sending them over the interface, then adding a new instrument would require only creating a new child instance of the class, and no changes to the main VI, at least for instrument settings. Maybe the instrument object could display its own front panel in the main VI panel, like a subvi can?

[Mark_Yedinak]

I think you are missing the point of OOP. One of the benefits of it is that it protects the class data from outside modification. To provide that access you would use access methods as stated above. By making your class data also be the UI you greatly reduce the reusability of your class. All of your user interfaces would need to be the same. By using the access methods and defining the UI separately you can easily modify what the UI looks like and then call the appropriate methods to set the data. Your code will be more readable and your abstraction will be better defined as well as more reusable.

[Thoric]

The object would be self-contained. Exposing the class's private data directly as a front panel object would defeat that security. Using the class's public methods and data member access VIs to edit the contained data in a controlled manner is what gives the class security. So long as you code it up that way 

It sounds like your class structure is typical, and that the scaling and settings ought to be private class data elements (as you suggest). Creating child classes to represent the different instruments would then be a sensible strategy. You still need to be able to pass the user data into the class, so creating a handful of Main VI front panel controls for the operator to use to select their settings, then calling the appropriate class VIs to pass these settings into the class, is a normal approach. Using inheritance, as you describe, solves the worry of having to create duplicate panels for each instrument type. In other words - you don't need bespoke front panels per child class, just one on the Main VI that is compatible with all.

[markrz]

I am wondering if I might do better with an XControl. In that case the data is a panel control, and methods can be invoked based on update events. I have not used an XControl before, so am not sure this is the best choice. Their doesn't seem to be any ineritance, but the XControl appears to be able to have the potential to translate user settings into instrument control strings, and send them over the interface to the instrument. There doesn't look to be inheritance, but maybe there is some useful ways of combining XControls and LVOOP?

[DFGray]

For the case you describe, a LabVIEW class is probably the better choice.  XControls bring a lot of power, but are simply customizable GUI components, and should be treated as such.  Yes, it will mean writing more code to get the GUI right, but, as has been often repeated above, that is a good thing.  Even without the class, this is still the model you should take.  Encapsulate your state data and interact with it in as decoupled a manner as possible.  If you want some throwaway code to check a concept, this is not the way to do it.  If you want modular, maintainable code, it is.  You just need more modules than you think you do ;).