Class automatic up-conversion bug?

[Michael Aivaliotis]

I have some class data that was flattened and saved in class version 1.0.0.1. I can open the data fine with my class of version 1.0.0.1. It's a complicated cluster structure with many sub-clusters. One of the sub-clusters contains an array of cluster data. When I try to read the data and unflatten it with my class of version 1.0.0.2, I get all the data back correctly with the exception of that one sub-cluster. the array comes back as empty. The unflatten function doesn't return any errors.

At this point i'm basically screwed. Any suggestions?

I love the idea of automatic up-conversion but right now I'm burned badly.

[Aristos Queue]

I have some class data that was flattened and saved in class version 1.0.0.1. I can open the data fine with my class of version 1.0.0.1. It's a complicated cluster structure with many sub-clusters. One of the sub-clusters contains an array of cluster data. When I try to read the data and unflatten it with my class of version 1.0.0.2, I get all the data back correctly with the exception of that one sub-cluster. the array comes back as empty. The unflatten function doesn't return any errors.

At this point i'm basically screwed. Any suggestions?

I love the idea of automatic up-conversion but right now I'm burned badly.

A) If you have version 1.0.0.1, you can try the edit again.

B) If that subcluster is a typedef, it is highly probable that autoconversion will fail for all the same reasons that typedef constants on diagrams loose their values. Classes lose a lot of their ability to automutate at the typedef boundary. Try disconnecting from the typedef in version 1.0.0.1 and then make the edit. Note that this is one of the reasons that I suggest using inner classes instead of subclusters, so you can have data preservation all the way to the roots of your data.

C) There are VIs in vi.lib\utility\lvoop to let you examine and modify the mutation records of a class. There's no real documentation for the format of the data and the notation can be arcane, but I think Kring has done some work with those VIs and may be able to help you ID the problem (assuming it is something other than the typedef thing).

[Michael Aivaliotis]

A) If you have version 1.0.0.1, you can try the edit again.

I'm not understanding this suggestion. Are you saying I should try resaving the data in 1.0.0.1? I already did that and it didn't help.

B) If that subcluster is a typedef, it is highly probable that autoconversion will fail for all the same reasons that typedef constants on diagrams loose their values. Classes lose a lot of their ability to automutate at the typedef boundary. Try disconnecting from the typedef in version 1.0.0.1 and then make the edit. Note that this is one of the reasons that I suggest using inner classes instead of subclusters, so you can have data preservation all the way to the roots of your data.

Even if this suggestion works, it doesn't help me at the moment. V1.0.0.1 of the class is already built into an executable and released to my customer. They've saved hundreds of records with that class data. The data exists and now I need to read it with my new executable that uses class v1.0.0.2.

C) There are VIs in vi.lib\utility\lvoop to let you examine and modify the mutation records of a class. There's no real documentation for the format of the data and the notation can be arcane, but I think Kring has done some work with those VIs and may be able to help you ID the problem (assuming it is something other than the typedef thing).

I found the following folder: vi.lib\utility\LVClass but nothing useful is in there.

[Aristos Queue]

I'm not understanding this suggestion. Are you saying I should try resaving the data in 1.0.0.1? I already did that and it didn't help.

No. I'm saying delete version 1.0.0.2 of your class and redo whatever edit you did to create version 1.0.0.2. The mechanism works by watching the edits you make to the class. For some reason, it thinks that array is new instead of a mutation from the previous version.

Oh, and I had the path wrong:

vi.lib\utility\EditVILibs\LVClass

[Michael Aivaliotis]

No. I'm saying delete version 1.0.0.2 of your class and redo whatever edit you did to create version 1.0.0.2. The mechanism works by watching the edits you make to the class. For some reason, it thinks that array is new instead of a mutation from the previous version.

Well, the array contains a typedef cluster and the change is adding a new element to that cluster.

Moving forward. What is the best practice in this case to support proper up-conversion? Should I disconnect all typedefs? Will that be enough, or should I convert them to objects? And if I switch to all objects, will the old clusters up-convert to objects properly?