I am trying to read and write to a simple XML file

[MarkBignell]

I have been trying to read and write values into a simple xml file. I can get the node name but not the value. I cannot see what I am doing wrong. I am obviously missing somthing very silly. Please put me right.

Best Regards, Mark

[Michalph]

I don't know, whether this is the best solution. But this is functional for example data.

[MarkBignell]

Thanks, this is the file I am using. I suspect some formatting issue so I will need to work around it!! Unfortunatly I did not generate the xml file it is generated outside my control. I just need to poke values into it. I will see if I spot the fault. Thanks for your input, this is my first venture into xml with labview, so, far it hasnt gone well. LOL

Mark

[MarkBignell]

So its all that formatting thats the issue. does the first line control the way the nodes are input. I have to delete all the type= and value= stuff to make it work.

[Michalph]

What value there looking for? At the first post the value is at: /Test/Section/p1, but at the xml file this hasn't.

Michal

[MarkBignell]

I am trying to read PaletteRemap0 in the xusb file I just uploaded. at the moment it is 3 but I want to change it to various values on the fly. The format of this file is very different. I am not up to speed with xml variations

[MarkBignell]

the first post was a much cut down file to help me to understand the mechanics of the input and output.

I have a nasty feeling I might need a schema?

[JÞB]

One large question.  Is the file being generated external to LabVIEW or do you have control of the source file?

Yes I ask for a reason.  Not too long ago I ran across a badly behaving chunk of code reading and writing a LabVIEW Class and an XML file.  Not too hard right?  just strip the class data member lables and values and you have nested tags and nodes similar to how you are parsing your file for 1 individual data member.  Of course when the average file starts getting into the Mbyte range, and you need most of the data members you need to call DOMUserDefRef.dll a few thousand times (DOMUserDefRef.dll is the resource the XML node is dependant on and, since its primary reason to exist it file IO, it is not threadsafe) the reads and writes started taking 2-3 seconds each.  Top that off with a few hundred files to iterate over and suddenly the 30 or so interrelated test systems grind to a slow march.

Since all the systems were dependant on the same Class and no other applications interacted with the files I looked into redesigning the file scheme to use the LabVIEW XML schema that encludes information on data type as well as tags and values.  File size of course whent up but ftp transfer speeds were still quite low and a method like the snippet below changed the speed of a simple write to file read from file operation from 5.9 seconds to 40mSec. (Exactly 2 calls to DOMUserDefRef.dll)

This is one of those times when classes (or just a clustersaurous if you must) and the LabVIEW XML schema can save you from XMHell. 

[MarkBignell]

i have no control over the input file

[JÞB]

---

@MarkBignell wrote:

i have no control over the input file

---

Your still going to be way ahead in effeciency treating the file as a string and get set values with string functions rather than depending on the XML Parser palatte.  From scanning your file it appears you only need to support two data types and clusters to contain them so writing your own parser will be fairly painless.