How to write a cluster and/or variant to a text file?

[tst]

Well, I wasn't aware that Commander handled dependencies, or I would have reported it.

Thanks for all the new releases.

[Jim_Kring]

---

@tst wrote:

Well, I wasn't aware that Commander handled dependencies, or I would have reported it.

Thanks for all the new releases.

---

You're welcome.  VI Package Manager does handle dependencies (Commander did not, by the way).  If you double click on a package in VIPM's package list, you will see a Package Information Dialog.  On the Details tab, there is a list of Dependencies for that package.

When you install a package that has dependencies, they will be automatically added to the installation list and selected for installation in the Action Confirmation Dialog, as shown below:



Thank you,

-Jim

Message Edited by Jim Kring on 02-17-2007 10:48 AM

[tst]

Incidentally, since we're talking about this package, there is a part of it which may be considered a bug (I'm not sure) - the package does not delete data from the file when data is deprecated from the cluster.

If this is a cluster element, then this is no big deal, because the extraneous element is simply ignored, but if you do this with an array with 3 elements when a previous version had 5 elements then the previous two elements will stay even though you only wrote a 3 element array.
I don't think this will affect anything other than arrays since they are the only variable-length structures which are based on elements.

Suggested solutions - add the size of the array dimensions (or if it's not found use the current method for legacy support) or delete the key before adding (race condition potential and changes the order in the file, not very nice in general).

BTW, I ran across this issue when I had to work on an application written by someone else while doing minimal changes. That application has a large main VI which does most of the work on a cluster which holds the data and is accessed through a local (luckily, only in one loop, so the data locking is OK). The VIs which were used to save and load the cluster were about 2 MB each and handled each element individually, so changing to the OpenG code was a welcome change.

Since the cluster holds some variable sized arrays I ran into this issue. My quick fix was to create a backup, delete the original, write the new version and then delete the backup, but this is obviously not a very nice solution. Due to time constraints I couldn't refactor the application to use GOOP either, which would probably have benefited it too, but that would "take too much time", of course.

P.S. If you think this is worth a discussion in the OpenG board, you can simply copy this text.

[Jim_Kring]

tst: Thanks for the suggestion.  Yes, it would be nice if the excess/unused array element keys were trimmed down.  This could be done by listing the keys and matching those with name-indices larger than the array size.  It shouldn't be too hard to implement, but it would be a performance hit -- but dealing with large config files takes a big performance hit, too.  I have added this to the to-list for the variantconfig library.  It will probably make it into the next release

Message Edited by Jim Kring on 02-17-2007 06:16 PM