Jump to content

Converting Typedefs to Classes

Recommended Posts

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)?

Link to comment

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.

Link to comment

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

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:


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... :unsure: 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?

Link to comment

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

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)

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.

Link to comment

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


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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.