Hah! I was not aware of these VIs. I had a play with it just now and was rather disappointed... that it works quite well.
However, I did find a few restrictions and have a few comments.
1) Data can only be saved to file. I use my VIs to parse data to/from a database and can be used to store it in any other medium that can take strings.
2) The field names are built using "." as separators, which means that a field such as "Cluster..Numeric" can be parsed in two ways, either "Cluster" and ."Numeric" or "Cluster." and "Numeric". Of course this won't be a problem, unless you have both cases in one structure. I know, this is beyond nit picking. In my database, I save each field name as an array of strings.
3) Clusters within the main cluster are saved as sections (I suspect this is intentional). This has the side effect that these cluster names must be unique.
4) <.size> is appended to indicate array size, which also restricts naming of your array. (Again, nit picking.) I am using the raw array name to store the array size to avoid this problem.
5) Recursion is used instead of iteration. This is just a preference, but I feel that one has less control over a recursive solution.
6) I noticed that timestamps are just flattened to strings. I checked this case in particular, because I had trouble with it.
7) The root datatype has to be a cluster. (I assume this is because it maps so nicely to a config file.)
It would be great if there were VIs that work like mine, but also VIs that automatically save to config files.
I have not had a look at the MGI version, but I will.
I have attached my VIs. I hope I have all the dependencies included. It's not very elegant looking and needs some cleaning up. Please have a look. Comments are welcome.
Christie
Strings - Control to & from String.vi
Tool - Array Element Default.vi
Strings - Variant to Strings.vi
Strings - Variant from Strings.vi
Strings - Variant from Strings - Commands.ctl