class object members vs clusters

[tlivingston]

One thing that was always cool about GOOP was the ability to treat the data as a cluster. For example, one could write code to quickly spit the names and values of members out to an .INI file.

Im noticing with LVOOP, I can't get the cluster properties for the member cluster. Its driving my crazy because i use this feature quite a bit. The only workaround ican think of is to drop a strict type def'd cluster in as the data but thats a layer of just i dont want.

Did i just not find this feature yet, or is it missing?

Thanks in advance!

[AristosQueue (NI)]

The data is accessed through bundle/unbundle, just as you would with a cluster. The bundling and unbundling of data can only be done on member VIs of the class because the data is private. To expose the data outside of the class, create member VIs that do the bundling and unbundling and make those VIs public.

The class wire does not break when connected to the Invoke and Property nodes. It should break since those nodes have no functionality for LVClasses. Classes use subVI syntax, not Property and Invoke nodes.

[tlivingston]

I want to programmatically get the NAMES and VALUES of all of the members.

you can do that with a cluster, you can not with class data aparently.

One can automate the saving and loading of entire data structures if you can get access to the data in a generic way. I used to do this with Vi's that acted on a reference to a cluster.

Im not looking to break the datflow model, i just want to be able to loop through the data members and generate an array of names.

[AristosQueue (NI)]

How do you get the names and values of a cluster? I don't know how to do this.

I do know how to get the names and values of a cluster control. If you want to get the names and values of a cluster control, then you can use the control on the FP of the private data control of a class.

Regarding this quote:
"One can automate the saving and loading of entire data structures if you can get access to the data in a generic way. I used to do this with Vi's that acted on a reference to a cluster."

Having it stored as a LV class is already a generic way of handling the entire data structure. The data could be of the class type or any child type. You can flatten and unflatten the child data as a parent type without loss of information. Any further genericization should be unnecessary.

Can you post a VI that shows what you do with a cluster so I can be more clear about whether/how to do it with a class?

[tlivingston]

The property node os a class control does not allow you to get to the "controls" property as does a cluster.

I dont want flattened data. I want to make an .ini file fill with select keys and values. Forget Why i want to do that, Ive justified that to myself already. I just CANT get the controls[] property of class data without making a cluster part of the data, then operating on the cluster by reference. With GOOp this was easy, with LVOOP it seems like i cant do it.

[AristosQueue (NI)]

I was asking the justification because I need to know if this is a facility of LVClasses that should be there (and so would be added in a future version) or if this was a facility that shouldn't be there and users like you should be guided to a different solution. I'm happy to work on workarounds when I think functionality is missing and make corrections a priority for bug releases if something is truly broken.

Having said all that, this sounds like a hybrid of both cases. Trying to get access to the data as a cluster *outside* of the class would be a major violation of the data privacy -- that would be exposing the implementation of the data to the world. Within the class, we do need an improved reflection API, although, as you pointed out, you could achieve the necessary behavior by using a strict typedef today within the class cluster.

Attached is a VI set that does what you asked for a class hierarchy without using a strict typedef. Open the project and then open DEMO.vi. I strongly suspect you won't be happy with the solution I've included, but perhaps something in there will help with your search for an acceptable solution.

PS: "I just CANT get the controls[] property of class data without making a cluster part of the data" is correct because there is no controls[] property to get access to. There are no controls, hidden or otherwise, within an LVClass control or indicator. There is only data. 

Message Edited by Aristos Queue on 02-06-2007 03:07 PM

[Jarrod_S.]

I understand that what you want to do is not directly exposed in LVOOP, but it doesn't sound like the workaround would be very difficult at all. It would involve creating a member function for your class that would write the values to the ini file. You would be correct to point out that this would be difficult to do for any generic class without using member functions, but it is extremely easy to do for a specific class.

There are two ways you could implement this. First, have your private class data be a cluster that contains a typedef cluster. Then all your member VI has to do is unbundle the private data, retrieve the inner cluster and write that cluster to file. OpenG has a great utility for writing clusters to an ini file that doesn't involve control references. Or you could use your method and extract the inner cluster of the private data into a dummy control and use a reference to extract the data names and values.

If you don't want an extra cluster layer in your data type, it's not a lot of extra work. Just unbundle all the elements of the private class data in your member function, rebundle them into a cluster with the same types of controls, and then use that cluster to write the data to file. You would probably want to typedef this cluster that mirrors your private function data so you can read in the ini values.

Message Edited by Jarrod S. on 02-06-2007 03:45 PM

[tlivingston]

That is exactly what Im trying to do. It seems like an awful lot of work to get more info about the data type.

What would be handy is if you could put a cluster within a member VI that had the same data type as the object. Currently, when you browse and select data.ctl from the class library, you get a class object, not its data type .ctl. Access to both would be cool.

Youve shown that the data type is indeed a cluster. The trick is getting that control open.

What I did with the GOOP model was copy the objects data into a temporary cluster, and use a function "ClusterRef to PV". Actually the real power of it was accomplished by making it recursive so that you could dump the configuration of an entire object hierarchy to a config file without writing a lick of code- Just pass it a reference to the Parent object.


Thanks for your tip!

[tlivingston]

Jarrod,

I use your exact method. I try to save time by automating the process. With goop I could act upon the datamember cluster, and its child classes recursively. It would save tons and tons of time from project to project. Debugging was always very time consuming with projects using 20-30 classes in a hierarchy.

[AristosQueue (NI)]

Thanks, Jerrod. Taking your solution and combining it with mine, it should become straightforward to generate a solution that will handle the cluster at every level of inheritance.