Converting Typedefs to Classes

[orko]

Well, I had some time finally to take some existing project data structures and see if I could convert them over to classes using the native LVOOP. At first, this seemed easy to do, with simple clusters. Then I tried a hierarchal cluster that included several other typdef clusters. Hmm. There must be a better way...

Taking an existing cluster that had typedef clusters inside and right clicking on it to convert it to a class, I would have thought that there would have been some easy way to convert the "subclusters" into classes as well. It turns out that even if after I converted the top cluster into a class, and clicking on each cluster contained in it and converting them to classes as well in the project, that the original typedef clusters were referenced in the main class instead of using the new classes I converted. Is there a trick I'm missing to do this sanely? I ended up having to weed through the dependancies, and find all of the old typedefs that were still being referenced...then finding them in the main top level class...then replacing them one by one with the new classes created from them.

To provide a simple illustration, typedef cluster A.ctl has two typedef clusters of type x.ctl inside of it. Converting A.ctl to A.lvclass leaves the two x.ctl's inside of it. I can see why this would be the expected behavior. But then converting x.ctl to a class in the project, the typedefs in A.lvclass are still not replaced. Replacing the first x.ctl with x.lvclass still isn't enough, so I have to replace the second one as well. You can see that if there are 10 clusters of differing data types inside of a main data cluster that I'm converting that this gets messy...without even thinking of clusters that are inside those second level clusters...

Is there an easy way to convert all of the clusters inside of a cluster into classes without all of this manual labor? Am I missing something basic (I wouldn't doubt it since I'm a LVOOP newbie)?

[Michael Aivaliotis]

Are you trying this in LV8.5? I just tried what you described and it worked as expected.

[orko]

QUOTE(Michael_Aivaliotis @ Sep 2 2007, 01:29 PM)

Are you trying this in LV8.5? I just tried what you described and it worked as expected.

Yes, I'm trying this in LV8.5.

As expected... what do you mean by that? I'm not sure yet if I'm not just fighting against the "expected" behavior, so it would be helpful if you could explain what you did/how the conversion went as opposed to my experience?

Thanks Michael.

[Yair]

I haven't read this deeply, and I'm definitely not an LVOOP guru, but it was my understanding that the class data type is private - it can not be used from anywhere outside the class. That would seem to me to be a likely reason why you can't do this.

[orko]

QUOTE(yen @ Sep 3 2007, 11:53 AM)

...it was my understanding that the class data type is private - it can not be used from anywhere outside the class.

Yes, that was my understanding as well. This is what was confusing me, because after converting the clusters over to classes as described above, this is what I get:

http://forums.lavag.org/index.php?act=attach&type=post&id=6842''>http://forums.lavag.org/index.php?act=attach&type=post&id=6842'>http://forums.lavag.org/index.php?act=attach&type=post&id=6842

This to me says that even though the class data is private, it is still depending on the type definition from the old strict typedef after I converted them over. In fact if you remove the old typedefs from the project they show up as dependancies until you release them from the class control (disconnect them from their typedef).

I guess I understand what is going on, and why...but I do not understand why this be desirable behavior... Why would I need to go through my entire class heirarchy after converting to classes and one-by-one disconnect them from their original typedef?

I guess my specific question, now that I understand what is going on, is this:

Why doesn't the "convert contents to class" project function release the new private class data from the original strict typedef control dependancy? Is there a reason this isn't done that I'm not thinking about?

[Michael Aivaliotis]

QUOTE(orko @ Sep 3 2007, 02:02 PM)

...after converting the clusters over to classes as described above, this is what I get:

http://forums.lavag.org/index.php?act=attach&type=post&id=6842

This is what I get as well. However, I didn't follow your point in the first post until now. The circled area is the key. You will also notice that if you double-click on the SubClust1.ctl in your example, the cluster has been replaced by an object icon. LabVIEW did the right thing but the question is, is it a bug, or an unfortunate side effect.

QUOTE(orko @ Sep 3 2007, 02:02 PM)

This to me says that even though the class data is private, it is still depending on the type definition from the old strict typedef after I converted them over.

Well, what I see, is that in your MasterCluster class, you have two objects of the type SubClust1. MasterCluster is not accessing any private data. It contains two instances of the SubClust1 class. What has happened (i think) is that now the SubClust1.lvclass object control has been typedef'd. The actual private data is not linked to the typedef. Class private data is not a typedef anyway. It's a special Class Private Data type. If you open up the class private data structure and right click on the cluster you will see that you can't customize it. This means it's not linked to the typedef.

QUOTE(orko @ Sep 3 2007, 02:02 PM)

I guess I understand what is going on, and why...but I do not understand why this be desirable behavior...

Why would I need to go through my entire class heirarchy after converting to classes and one-by-one disconnect them from their original typedef?

As I discussed, the new class private data IS disconnected, so there is no real problem here. I agree it's a little annoying and perhaps an autodisconnect should take place, but if that happens then it might not be expected and could confuse those that expected it to behave the way it does.

[orko]

QUOTE(Michael_Aivaliotis @ Sep 3 2007, 10:00 PM)

Well, what I see, is that in your MasterCluster class, you have two objects of the type SubClust1. MasterCluster is not accessing any private data. It contains two instances of the SubClust1 class. What has happened (i think) is that now the SubClust1.lvclass object control has been typedef'd. The actual private data is not linked to the typedef.

Hmm... I understand that this looks like the SubClust1 class has been typedef'ed. Okay.

What I still don't understand is why the original typdef cluster (SubClust1.ctl) is linked as a dependancy after the classes are set up. You can see this by deleting the SubClust1.ctl and MasterClust.ctl from the project and refreshing the dependancies.

Why is the project now dependant on the SubClust1.ctl? What is still using it?

EDIT: OHHH.... I understand. The SubClust1.ctl has *BECOME* the typedefed SubClust1 class! Oh my head... that IS confusing. But it makes sense what is going on now (although I'm still not sure if it is "correct" or sane behavior to typedef the class in this way)!

http://forums.lavag.org/index.php?act=attach&type=post&id=6844''>http://forums.lavag.org/index.php?act=attach&type=post&id=6844'>http://forums.lavag.org/index.php?act=attach&type=post&id=6844

[Aristos Queue]

A) Please file a bug report on ni.com/devforums if the documentation is unclear for this feature. The online help is at

National%20Instruments/LabVIEW%208.5/help/html/lvhowto.chm/control_to_class.html

B) Here's some details of what is going on...

1) You popup on X.ctl and select Convert Contents of Control to Class

2) A new class is created named X.lvclass which contains X.ctl, the private data control of this class. This is NOT the same X.ctl as the one on which you popped up.

3) The private data control's cluster is populated with the data from the original X.ctl.

4) The original X.ctl is edited to have an instance of X.lvclass on its front panel, replacing whatever else was there already.

The original X.ctl is not deleted so that VIs that look for it can still find it. Whenever you open a VI that uses X.ctl, that VI updates to match X.ctl (assuming X.ctl is a typedef). Thus any VI that used the old X.ctl type now uses the new X.ctl type, which is X.lvclass. Any VI that just passed the X.ctl value around to subVIs is fine. Any VI that tried to actually operate on the value of X.ctl is broken. To fix those VIs you need to move them inside the new X.lvclass so that they have the priviledge of being able to access the data OR you need to create accessor VIs on X.lvclass that these broken VIs can use.