Disconnect all typedefs in a CTL

[Vladimir Drzik]

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

[shoneill]

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.

[Vladimir Drzik]

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

[Yair]

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.

[LAVA 1.0 Content]

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

[Vladimir Drzik]

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

[Aristos Queue]

QUOTE (Vladimir Drzik @ Apr 1 2009, 12:53 AM)

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?

Lots of documentation... it's one of our "six major reasons why you should use LV classes" that I presented at NI Week 2008. I linked to a bunch of stuff in http://forums.lavag.org/LabVIEW-Class-Data-Preservation-Details-t11259.html' target="_blank">this forum post.

[Yair]

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.

[Vladimir Drzik]

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

Lots of documentation... it's one of our "six major reasons why you should use LV classes" that I presented at NI Week 2008. I linked to a bunch of stuff in http://forums.lavag.org/LabVIEW-Class-Data-Preservation-Details-t11259.html' target="_blank">this forum post.

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

[battler]

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

[Darren]

Here's a Quick Drop shortcut that will do a recursive typedef disconnection:

 

https://decibel.ni.com/content/docs/DOC-37041