create multiple xml attributes

[DianeS]

Hi all,

I'm not terribly experienced with the LabVIEW XML functions...so far I'm finding them to be a major pain in the fanny, actually.  I've gotten as far as being able to parse an existing xml file, but now I need to write one.

The file I'm trying to write is pretty simple:  a single tag with multiple attributes.  Because multiple data sources will be creating these files, I don't have the option of happily using the LabVIEW schema and trusting that everything will be fine.  Besides, those functions don't give me enough visibility into what's getting written where and how, and I'm nervous about "black boxes" -- I like to know exactly what's happening and where, when I write code.  Therefore,  I have to use the XML functions to create this file instead.

A search on the forum revealed code to create a single attribute.  When I try to adapt this code to create multiple attributes, I get error -2602:  Inserted node in the wrong location.

Can someone please look at this example and tell me where I blew it?  I'm sure it's something dumb, but I can't see it.

Thanks everyone!

Diane

[Bob_Schor]

I'm not an expert on XML, but you might take a look at EasyXML from JKI Software (the folks who bring you VI Package Manager).  I'm pretty sure it supports multiple attributes (and is "Easy").

Bob Schor

[DianeS]

Thanks for the response.

That's not really an option for me, actually.  I've certainly heard of EasyXML (I've been poking around on the forums for the past few days as I played with the XML functions), but there's no telling in advance where / how this code may be deployed or who else might work on it.  And any other developer who plays with it in future probably won't have EasyXML anywhere on their machine, which means they'll come crying to me because they can't load the code.  So I'd have to package it into the project and drag it around.  Which is a pain, and I don't even know if I'm legally allowed to do that.

If I just use the basic LabVIEW VIs, I know that anyone else here can work with the code if I get hit by a bus.

I feel like I'm most of the way there and I'm making a basic mistake, but I can't see the forest for the trees.

[GregFreeman]

---

@DianeS wrote:

Thanks for the response.

That's not really an option for me, actually.  I've certainly heard of EasyXML (I've been poking around on the forums for the past few days as I played with the XML functions), but there's no telling in advance where / how this code may be deployed or who else might work on it.  And any other developer who plays with it in future probably won't have EasyXML anywhere on their machine, which means they'll come crying to me because they can't load the code.  So I'd have to package it into the project and drag it around.  Which is a pain, and I don't even know if I'm legally allowed to do that.

If I just use the basic LabVIEW VIs, I know that anyone else here can work with the code if I get hit by a bus.

I feel like I'm most of the way there and I'm making a basic mistake, but I can't see the forest for the trees.

---

Have you considered using VIPM to resolve that issue? I know it's not solving your problem, but if the only issue is they will be missing the EasyXML toolkit, that's a relatively simple problem to solve. I also don't have much experience with the LabVIEW XML VIs, but (again, not helping you) I feel your pain, as when I have used them it has been frustrating.

[Darin.K · Accepted solution]

You were very close.  Just move the append child method outside of the loop and you are all good. The child is the element, so you build it (name, value, attributes) then append it.

[TroyK]

I stopped using the inbuilt LabVIEW XML parser functions. They are too slow and don't give you the 'visibility' as you put it.

I'd recommend using the libXML parser. It's free/opensource and about 20 times faster than any other solution I've tried.

There is a LabXML wrapper library made for it but I had to tweak it to get the better performance. See here.

Parsing XML is too slow, or is it?

[DianeS]

Darin, you've come through for me yet again.  🙂  Thank you so much!!  I knew it had to be something dumb, or obvious, or both.

Troy, I'll check out your links for my own interest and knowledge, but again, the problem with using any opensource or package, etc. (I do have VIPM and sometimes use it, but not all of the developers on my team do) is that then I have to carry all those VIs around with the project that uses them.  I can't guarantee that only my team members will be working with my code.  If I could, life would be easier...but oftentimes other groups, who have a few folks who kind of know LabVIEW, use my team's work as a basis for code they develop.  Those folks will scream and throw fits and come knocking on my door if they try to open one of my projects and can't because I've used a bunch of open source external code that they don't have.

(They complain enough as it is that our stuff is too advanced for them to understand.  Our unsympathetic response is "learn to program".)

Anyway.  I do agree that the built-in XML functions for LabVIEW are pretty clunky, take a long time to execute, and aren't very well documented (especially the property and invoke nodes), but for now I'm stuck with them.  I'm always interested in learning more, though, so thanks for the links!

So thank you again, Darin!!!  You're the best!

Diane

[TroyK]

Hi Diane,

Don't you have some sort of source code control/configuration management tool like Subversion/GIT/ClearCase to manage shared code and libraries?

We have semi-experienced people reusing code here too, we just force them to follow good software development practices even if it isn't their field of expertise.

Instead of having hardware and VIPM managed libraries installed on individual machines, it is put into source control and then everybody has it when they need it.

Troy