Anything more flexible for reading/writing XML?

[hecmar.arreola]

Hi!

I have been using the Read from XML File and Write to XML File VIs that ship with LabVIEW for some time now.  I generally pass some control values to an XML file when a user exits from one of my programs, and then read from that XML to reload the last state of the control when my user opens my program up again.  This works well and makes it easy to implement features such as multiple config files.

I wonder if there is a better method for doing this.  I'm not stuck on XML as my filetype for config files, but I do find that it translates to and from clustered controls well.

The issue is that a change in a program that requires a change in a control or even an addition/deletion of a field or control to a cluster renders all of my XML files used in previous program versions useless since the XML structure has changed.  Is there a better way to accomplish this "saving" and "loading" program state date from files such that loading the information is persistent if the structure changes?

I'm getting tired of having to doctor user's config files because of changes to my program.  Thanks for your advice.

-nic 

[smercurio_fc]

• You could define your own XML format and just use the XML Parser VIs (assuming you have a LabVIEW version that has those). If you don't then you can use LabXML.
• OpenG has a set of VIs that you could use.
• You could use "regular" .ini files and use the Configuration VIs.

[tbob]

You could use the Labview Config Files.  You can name sections, and each section holds keys.  Each key has a value.  You can add sections and keys without breaking previous code.  I've used config files many times to hold program settings and other information that needs to be loaded upon startup.  It works very well.  Config files are also readable by Notepad or any text processor.  They sort of look like registry files:

[section1]

key1="name"

key2=25

You can get the value 25 by specifying "section1" as the section name, and "key2" as the key name and use the Read Key function.  In my opinion, for what you want to do, Config files are better than XML files.

[hecmar.arreola]

Thanks for the reply.  I have used "regular" .ini files in the past and found them to be painful.  Too much micro-managing of the information.  Maybe I'm not doing it right.... my implementations of the past have left a lot to desire in terms of elegance.  

I do love how w/ the XML it will accept "any" format and the structure it creates in the file.

To simplify things, my problem is really only 1 direction.  Writing a file is clear cut and there will never be a version conflict because my program is aware of the structure that it is currently writing.  Reading is where the problem presents itself.  I will look to see what OpenG has to off and if they work for me.  I think something that will read an XML and make a good attempt to match values to the correct controls within a cluster is what I am after.  

For instance, a cluster might have the controls labelled "Control1", "Control2", "Control3" in one version of the program.  In the next version I might add "Control4".  When reading the saved XML file from the old version of the program (sans-Control4) it seems like the best course would be to load the values for Control1, 2, and 3 and then load the default value for Control4.  Etc.

Hopefully I can find what I am looking for, because I don't have much interest in messing with the low-level XML vi's :D.  I'm too lazy for that.  LOL. 

[hecmar.arreola]

Hi tbob,

Thanks for the reply.  I respectfully disagree.   The problem I have with config .ini files is that there needs to be special knowledge written in the code about what is "named" in the config file and where does it go in my program.  This works OK for small stuff.  But for larger arrays of clusters this becomes a problem.

For instance, often my programs contain State Controllers which consist of an array of clusters and each of these clusters represent the output to physical controls (such as turning valves on or off, or rotating a stepper motor in a particular direction at a particular speed).  These arrays may contain a hundred instructions.  This is a situation where plugging it into the XML file VI handlers works like a charm (so long as I don't mess with the data structure).  If I were to handle the nitty-gritty of the Config files I would probably spend as much time developing a Config file scheme as I would programming my State Controller, and that is undesirable.  Unless I am missing something.....? 

[tbob]

If you have hundreds of instructions (keys to store), then config files would be very cumbersome and would take a lot of work to create.  I didn't know the volume of information you were talking about.  Config files are good for a small number of items to store.

[blawson]

It sounds like what you need is a way to version your config files.  This is a problem that I think is independent of the file format and has more to do with how you use them.

So you have a type deffed cluster that you are using for configuration and it's been used to create data you don't want to lose, but now you want to change it.  When you change the typedef, everything using that TD updates nicely, but the old data is left out in the cold, it doesn't fit the cluster anymore.  So before you change it, copy the typedef and name it as an old version.  The file that's hooked in to everything is the working version.

Then go into whatever config file routine you have and change it.  You need to write code for converting the old cluster into the new cluster.  Maybe you raise a dialog prompting the user to fill in the missing information, maybe you fill in defaults.  In the code where you load the file from the config, test loading with the old cluster, if it fails, try the new cluster, if that fails, it's a bad file.  This also works when you have more than two versions of your config file in the wild.

The file format particulars will shake out in how you test for one version or the other.  I don't know the XML tools well, but if you can read an individual tag, perhaps including a version number can work.  I like to save the cluster(s) straight to binary so that makes it easy - if its the wrong datatype you get an error.  as to converting clusters, openG vCluster tools make it extremely easy to manipulate clusters by element name and what have you.  I've posted about this before, let me see if I can find the image...

  

this snippet creates a New Cluster using all the elements in Old Cluster that match by name.

[shew82]

One thing that can REALLY help with the whole cluster-change-breaking-XML file thing is to use a object (lvclass) instead of a regular cluster. When those clever guys over at NI put in the LabVIEW object orientated programming code, they put in some "special sauce" that allows class files to automatically update when unflattening from XML.

Basically, when the object is saved as XML, it has its version saved with it. Then, when you make  a change, LabVIEW bumps the version number and stores (in the lvclass file) how to convert version X to X+1.

In this instance, you dont need to do / know too much about classes (if their unfamiliar to you) but a class "private data cluster" can only be (un)bundled by VIs that are part of the class. This means you will need a few "accessor" VIs to use in place of regular (un)bundle nodes.

I end up doing this ALL THE TIME for my config files!

Shaun 

[hecmar.arreola]

This is all very good input guys.  Thanks for the replies.  I'll play around with a few of these ideas and see if I can get something reasonable working for me.  Its one of those problems I've kept pushing off but when one of the engineers needs a design change it is sometimes devastating for them to have to re-write their process in my code because their old XML files won't work with the new implimentations.

@shew82 - thats a really good idea.  I've been using OOP in LV a lot lately and it does seem to address the problem well.  My OOP skills are still in their infancy.  I know my way around OOP but i'm not a very graceful designer in it yet (practice makes perfect, and so do good references). 

[JackDunaway]

---

Nickerbocker wrote:

This is all very good input guys.

---

I agree! Also, extensibility support for Version Tolerant Unflatten from XML would be a big step toward config file versioning.