write class data

[Ben · Accepted solution]

There is one thing that you could try that may get you close to what you want but it requires introducing a non-elegent cludge.

Create a type def'd cluster that matches your private data. Poke and prod at a control of the type def'd cluster and then inside one of your methods wire the type def to the class data... Idon't think you can wire it directly but a unbundle wire dto a bunlde may be legal.

If that works post an image.

If it does not please don't hold it against me.

Ben

[DAckermann]

Yes, this seems fine for me. You can take the class definition cluster and copy right away in a cluster typedef. So it is not too much work. You just have to make sure, that the two definitions always match.

[Ben]

---

@DAckermann wrote:

Yes, this seems fine for me. You can take the class definition cluster and copy right away in a cluster typedef. So it is not too much work. You just have to make sure, that the two definitions always match.

---

Yes, that is the part that seems unweildy.

Ben

[SteveChandler]

I am still trying to follow what you are trying to do, but why not just wire the class through your "Cluster INI" VI and get rid of the control reference and cluster altogether? The Cluster INI.vi does not have to necessarily be part of the class. Inside of it you can bundle whatever you want into the class data If Cluster INI is part of that class or otherwise modify the data with accessors.

[Ben]

---

@Steve Chandler wrote:

I am still trying to follow what you are trying to do, but why not just wire the class through your "Cluster INI" VI and get rid of the control reference and cluster altogether? The Cluster INI.vi does not have to necessarily be part of the class. Inside of it you can bundle whatever you want into the class data If Cluster INI is part of that class or otherwise modify the data with accessors.

---

"Cluster INI" can be wrapper around a common VI used for all classes and if written correctly will will adapt to the cluster contents.

He can have huge private data sets and rather than having to write a method for each filed he wasnt ti init from a ini file and the only thing the developer has to do is make sure the type def of cluster matches the private data.

Ben 

[DAckermann]

That's right. The cluster ini file vi does not change. It's loading the ini file controlled by the elements of the cluster reference wired to it into the cluster. So I just have to create a cluster type def and do not have to do any more programming. The ini file keys are the cluster element names. This approach saves programming work. Unfortunately this does not work with classes, because you can not get acces by reference to the class data elements. Getting this access from inside a method would be enough.

I could use the Labview native functions that is saving and loading class data in a kind of xml. But I needto have ini file format so I or a user can edit the files easily.

I still have data access methods to the elements. But it would be much more work to do the initialization of an object by ini file with coding each entry with a read key vi and a data access method.

[Ben]

---

@DAckermann wrote:

That's right. ...

. But I needto have ini file format so I or a user can edit the files easily.

I still have data access methods to the elements. But it would be much more work to do the initialization of an object by ini file with coding each entry with a read key vi and a data access method.

---

Thanks for confirming.

I the interset of completeness what we loose is the element by element over-ride capbilities.

Example:

Say your customer decided they wanted to use a tab-delimted file for the configuration, you would have to implement another method eg Init_From_SS and the code using the original form would also have to be modified. If you are working in regulated industry the code would have to be recetified.

But if you used a different approach that decoupled the init from the file type then you would only have to test and certify the init functionality.

I will share an approach that I have been using and welcome others in commenting on the short comings.

Classes like what we are dealing with in this thread need an Init method and use a file path. If I add a "File" class to the private data of the the class i want to init, I can use over-ride VI's to support different file formats. If I then implement my Init methods in the form "Init yourself" I remove the requirement that the class know how to init its parts a thereby reduce the coupling between the class and the file type.

Just my two cents,

Ben