App Files Saved as XML and Working with New Versions

Question

We work with app data in the form of array of large clusters and use LV Anything to XML conversion VIs to save to disk.
The problem is when new app versions are developed and changes are made to the cluster format; we want the customer to be able to open the old version saved XML file format.
Usually the saved cluster (in XML) has be changed by adding/removing a field or even changing the options of a ring control for example.
The app name and version is stored in the XML.
Question: Is there a way of easily working with XML file formats with slightly different fields?
In the past we have worked with the raw XML text by searching for fields which are different and modifying them accordingly so they are accepted by the new file format.
Any tips would be greatly appreciated.

Answer 1

battler. wrote:
I have written a software name and version cluster to XML.  How do you read the version field in the XML?  Do you use string search?  Is there a better way?
Yes, I use String Search (because it is near the beginning of the XML string).  Depending on your XML "flavor", you should be able to uniquely-identify the Version information.
I'm interested in how best to work with XML.  It seems cumbersome and prone to error to use string functions.  Is there a way or best practice of reading the XML fields directly without converting to cluster?
XML is, after all, text with specific "tag" information, also text, identifying it.  String functions are pretty much "the way to go", but except in rare circumstances, you shouldn't necessarily "roll your own", but should try to use the utilities that come with your XML package that "know" how to do the mapping between the XML representation of a LabVIEW variable (and its value) and the Variable itself.
Can you elaborate on these "mapping" and "reading/conversion" routines you're using?  How do they work and what functions do they use?
An excellent question.  There are at least three XML packages out there for LabVIEW -- the "native" LabVIEW package that NI provides, EasyXML from JKI Software (distributed using VIPM), and GXML, also on the LabVIEW Package network.  I'm afraid that I'm slightly "abusing" XML, and have made some modifications to how I use EasyXML and GXML. 
If you simply view an XML file in a "smart" editor, you'll see a series of text lines with Begin/End tags (like HTML).  Depending on the XML "flavor", embedded between the tags are data that describe the LabVIEW variable type (e.g. Dbl, Cluster, Array, etc.) and also the value(s) of the Variable.  The "ReadXML" (or similarly-named) function takes this description and (usually) returns a Variant that you can "turn into" the chosen variable (because you know the data type).  [You may need to tell the Reader, in advance, the type of LabVIEW variable to expect so that it "knows when to stop reading"].
As to how they work, they just do String pattern matching and processing, usually of a pretty sophisticated level, but then you don't have to do the hard work yourself!
Why do you use Private Project library?  Is your project based on OO?
The reason I used a Project Library with the "messy details" in the Private parts has nothing to do with OO, but rather with "data hiding".  I actually developed this for my data processing routines.  I had a set of routines that collected and analyzed the data (about 700 VIs).  Let's call this Project "Version 1".
For Version 2, I basically added a dozen variables to the main  Data Cluster (having over a hundred elements) that characterized the response.  As this Cluster was in a Type Def, I didn't have to change my code very much to accomodate this new data format, so most of my VIs kept the same name, but were "different" because the underlying TypeDefs were different.
So I have a Version 1 program that can analyze Version 1 data, and a Version 2 program for Version 2 data.  What I want is a Version-independent program that can look at the data, and then call for Version 1 or Version 2 analysis.  By burying the Version 1 and Version 2 code inside of a Project Library, and only exposing the top-level "Analyze My Data" VI, my Analysis routine, which didn't know (and didn't care) about the two different Data TypeDefs, just figures out (from the XML) which Version of data I have and then calls either Lib1:Analyze My Data or Lib2:Analyze My Data.  If I ever change the Version again, I just need to copy the code in the Library to a new Lib3 Library, modify the TypeDef and related version-specific code as needed, and I'm done.
I may have made this sound easy -- trust me, it was a definite learning experience.  While trying this out, the first thing I did was to "break" my installations of LabVIEW 2012, 2013, and 2014 (curiously, LabVIEW 2011 wasn't broken).  It stayed "broken" for about a week, then "cured" itself (I'd done something illegal, or maybe just immoral, with my Library, and it took a while to purge the badness).
BS