QControl Enthusiasts

cancel
Showing results for 
Search instead for 
Did you mean: 

Best practice for State data vs. Class data?

Solved!
Go to solution

In a given Qcontrol, I can store "stuff" about the Qcontrol in either its State data or its Class data. I assume that, since Qcontrols are designed to be by-reference, that everything within it needs to be part of the State data (which, being a DVR is by-reference), but then again the Control reference is stored in the Class data itself.

 

I know in the Event handler, the QControl is only read once (it isn't looped through the Even handler via Feedback nodes) so anything stored in the Control is basically "write only during creation".

 

My gut is that it's OK to put stuff in either location, as long as you're OK with read-only access to the Class data itself, but I'd be interested to better understand the best practices here.

Message 1 of 2
(2,649 Views)
Solution
Accepted by topic author BertMcMahan

It is true that data can be stored in either the State Data or the Class Data.  However, what you can do with each is different. 

 

A QControl with an Event Handler runs in two parallel threads.  The first thread is the Event Handler and the other thread is your main application where properties and methods on the QControl run.  The reason the class is by-reference is to allow both threads access the same memory.  By-reference in this case means that the Class Data should only contain references (i.e. the control's reference or multiple control references, the State Data DVR, and possibly other User Events or Queue references as needed).

 

This being said, you still could have other non-reference data in the Class Data as long as you realize that the data cannot be updated and remain in sync in both threads.

 

So why might you want to do this?  You might want to do this if you have initial configuration data that won't ever change after the initial creation.  You could populate this data through an input to the Constructor method if the data should be variable from instance to instance of use, or your could populate it in the Initialize Control method if it should always be the same but you want a simple place to modify it.

 

As for best practices, currently there are none specifically to QControls (or none that can be simply stated as yet).  I would follow best OOP practices and other coding standards.  I have intentionally left QControls very open and flexible because I don't know what they will need to be used for. Best practices will evolve as the community adopts them and learns from them.  I think that this post qualifies as a good start as a best practice to data handling in QControls.

Quentin "Q" Alldredge

Chief LabVIEW Architect, Testeract | Owner, Q Software Innovations, LLC (QSI)
Director, GCentral | Admin, LabVIEW Wiki | Creator, The QControl Toolkit
Certified LabVIEW Architect | LabVIEW Champion | NI Alliance Partner



Message 2 of 2
(2,635 Views)