LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is it safe to Coerce To Type a Node refnum to an Element refnum?

I haven't had to do much XML processing with LabVIEW before and am trying to construct a SOAP web service request. Is it safe to use Coerce to Type to convert a Node refnum (returned by Get First Matched Node) to an Element refnum? None of the built-in examples show a recommended way to do this.

 

It's just a lot more convenient to look up an Element with XPath and use the Set Attribute method, rather than Create Attribute, Create Text Node, append the text node as a child of the attribute, look up the Node, get its attributes, then call Set Named Item to add the new attribute.

0 Kudos
Message 1 of 5
(1,442 Views)

If you have a constant of the Node type and right click it you can see that Node is the parent of Element:

Kyle97330_0-1677533485278.png

There is also a Type property of the Node reference you can get that has these options:

Kyle97330_1-1677533579426.png

These are almost but not a complete 1:1 match.  I would speculate that anything that returns "Element_Node" as its Type property would be castable, but I can't prove it would be true 100% of the time.

 

As a side note, the built-in LabVIEW XML processing, while it is functional, is pretty slow when you start giving it large XML chunks.  If you're only using small ones then you should be fine, but if you're using large ones (10k+ characters) I would strongly recommend looking into alternate XML libraries:

 

https://forums.ni.com/t5/Example-Code/Libxml2-Parsing-XML-in-LabVIEW-is-too-slow-or-is-it/ta-p/34926...

 

 

Message 2 of 5
(1,402 Views)

Right, I get that Element inherits from Node in the XML DOM and the Get First Matched Element has to return a Node, because it doesn't know what its XPath refers to. I do know that the XPath I'm using will cause GFME to return exactly one Element. If these were Node and Element classes, I'd be comfortable using To More Specific Class to change the type of the wire, but refnums are basically pointers to a memory location (as I understand it), so I'm not sure if it's safe to be changing their type like this.

0 Kudos
Message 3 of 5
(1,394 Views)

Real refnums in LabVIEW are a bit more than pointers. But there is a chance that some code hides a pointer behind a fake refnum, however that would disqualify such a library to be ported to 64-bit like that.

 

The XML DOM library uses real refnums and the worst that can happen is that the To More Specific returns an error. So try it out and if it works, you should be safe. If it doesn’t that Node is a Node and not an Element disguised as Node.

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 5
(1,345 Views)

Thanks for the responses. Since it's not clear if it's safe to cast a refnum like this and I don't want to have it suddenly stop working right at runtime if the data changes, I decided to go with the more verbose method.

0 Kudos
Message 5 of 5
(1,113 Views)