Jump to content
Vladimir Drzik

Disconnect all typedefs in a CTL

Recommended Posts

Hi

I use a very large cluster, consisting of many nested type definitions. For this cluster, I keep the complete version history, i.e. each version of the cluster is a separate file. In this file, however, I no longer want to autoupdate the nested clusters when my typedefs change. That's why I'm disconnecting all the typedefs each time I create a new file (new version).

This takes quite a lot of time. Can you think of a simple way how to do this "batch disconnection" more simply?

Vladimir

Share this post


Link to post
Share on other sites

QUOTE (Vladimir Drzik @ Mar 31 2009, 02:50 PM)

Hi

I use a very large cluster, consisting of many nested type definitions. For this cluster, I keep the complete version history, i.e. each version of the cluster is a separate file. In this file, however, I no longer want to autoupdate the nested clusters when my typedefs change. That's why I'm disconnecting all the typedefs each time I create a new file (new version).

This takes quite a lot of time. Can you think of a simple way how to do this "batch disconnection" more simply?

Vladimir

Well, why don't you save the control as a normal control instead of a Typedef.

Shane.

Share this post


Link to post
Share on other sites

QUOTE (shoneill @ Mar 31 2009, 04:47 PM)

Well, why don't you save the control as a normal control instead of a Typedef.

Shane.

While my large cluster is in its current version, it's good to have all its nested data typedefined. But before I make any change to the data declaration of the large cluster, I always make a copy of its current state into a version history folder. But the copy has to be "frozen", so that it does not change in the future when the typedefs are modified. That's why I need to disconnect the typedefs.

Vladimir

Share this post


Link to post
Share on other sites

I don't have LV in front of me, but it's fairly easy to open a reference to the control (use Open VI Ref) and recurse through all the typedefs it calls using the Callees property and then calling the Disconnect method on each of them. Make sure the control isn't open in a VI which is in a non-idle state. Also, make sure to limit the scope of which typedefs you're disconnecting (e.g. you probably don't want to disconnect vi.lib typedefs). Jim Kring had a post on his blog once about doing this and may have even uploaded some code.

The better advice I can offer, however, is to use another method. Some options include LVOOP, the OpenG variant config VIs and MGI's read-write anything VIs. They allow you to open older versions, newer versions, etc. without having to write any additional code and work very well.

Share this post


Link to post
Share on other sites

Here's a tough one:

Disconnect a Typedef with a Registration Refnum.

The Registration Refnum contains a User Event with a TD-control.

I cannot get LabVIEW to disconnect from the TD inside the user event, only by removing the TD.

Ton

Share this post


Link to post
Share on other sites

QUOTE (Yair @ Mar 31 2009, 06:59 PM)

The better advice I can offer, however, is to use another method. Some options include LVOOP, the OpenG variant config VIs and MGI's read-write anything VIs. They allow you to open older versions, newer versions, etc. without having to write any additional code and work very well.

Thanks for help guys

Yair, are you serious that you can open older versions of LVOOP objects? Never heard about that... How does the conversion work? Is there any document that describes the mechanism?

Vladimir

Share this post


Link to post
Share on other sites

QUOTE (Aristos Queue @ Apr 1 2009, 04:20 PM)

Lots of documentation...

Maybe, but the OpenG/MGI method (loading elements by name) is a lot more intuitive and seems to be somewhat safer (e.g. I hate that renaming a class causes it to lose all its history. I was cleaning up code for release and decided to rename one of the UUT classes from the development name it had to the production name the customer finally decided on. Big mistake, since that meant I couldn't load old configurations anymore, because the config class had an array of UUTs. Luckily, it didn't matter in that case, so I didn't need to revert. If I was using one of the other methods, I would get default data for that and the rest would load fine).

I'm guessing that the LVOOP method is faster, but in most cases I don't think that loading and saving things like this is critical.

Share this post


Link to post
Share on other sites

QUOTE (Aristos Queue @ Apr 1 2009, 03:20 PM)

Nice. However, sometimes I'd like to be able to do a special data conversion from the older version. Is there a VI that can get the object's class version from the flattened string? Yes I know I can do it by parsing the string...

As Yair has already said, the bad part is that the version history is lost after renaming of the class. Well, maybe that could be solved (in rare cases) by manually renaming the class on disk to keep its version history and modifying the flattened strings by parsing and regenerating them with a different name.

Vladimir

Share this post


Link to post
Share on other sites

Drop the cluster onto the BD as a constant.  Any typedefs inside the cluster will have the black coloured triangle at their top corner (LV 2014 I'm using).

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
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.