XControls, XML Parsing, XProblems

[Murugan]

I am using an Action Engine (Functional Global) to maintain a reference to a DOM Document, with several states for manipulating the document. I call the action engine VI from XControls on Init and Uninit, so that there are XML elements that are added/removed from the action engine when the XControl is added to or removed from a VI. I am able to add many copies of the XControl without problems. Often I can go on adding and removing XControls several times. Randomly, however, I get a warning 15 related to the XML Parser, stating that the DOM Document resource is invalid. From this point on, I am no longer able to make modifications to the document--I can view the XML associated with the DOM Document using Get XML, but am not able to manipulate it in any way. It is as if the object or reference has become corrupted.

Is there a known bug related to this? If I run the action engine independent of the XControl I do not get this problem. Do XControls have a tendency to corrupt references contained in VIs external to the XControl?

I am using LabVIEW 8.6. Thanks for any help.

[Rolf Kalbermatter]

I am using an Action Engine (Functional Global) to maintain a reference to a DOM Document, with several states for manipulating the document. I call the action engine VI from XControls on Init and Uninit, so that there are XML elements that are added/removed from the action engine when the XControl is added to or removed from a VI. I am able to add many copies of the XControl without problems. Often I can go on adding and removing XControls several times. Randomly, however, I get a warning 15 related to the XML Parser, stating that the DOM Document resource is invalid. From this point on, I am no longer able to make modifications to the document--I can view the XML associated with the DOM Document using Get XML, but am not able to manipulate it in any way. It is as if the object or reference has become corrupted.

Are you using the LabVIEW DOM library from the Internet Toolkit or simply accessing an XML ActiveX interface?

In both cases you may be running into LabVIEWs automatic garbage collection for refnums. Once the top level VI in whose hierarchy a refnum was created goes idle (stops executing) LabVIEW will automatically dispose of that refnum (and the objects they reference).

I'm not familiar with X controls nor how they work but if your XControl creates the refnum in some initialization state that goes idle afterwards the object goes invalid at the moment your initialization stops. How to solve that? Initilize the object in a context that will stay running for the desired lifetime of your object.

[Murugan]

You hit it on the head, that was the problem, and I fixed it. XControls are little reentrant VIs that run as soon as the control is dropped on to a VI in edit time. Because there is a strange interplay going on between some things being in edit time and others in run time, I can see how LabVIEW might think that all callers to a functional global VI have been closed and clean up the references.

So here's the rule: When building XControls that call functional globals, be sure to initialize/shutdown the FG independently of the XControls.

This happened because XControls are supposed to be self-contained, so that I shouldn't have to manually run other VIs before dropping XControls down on my front panel. This "self-containment" principal can still be followed by dynamically running a loader/unloader VI that initializes and shuts down resources such as functional globals, and remains running as long as an XControl that needs those resources is loaded.

Thanks, rolfk!

[Ton Plomp]

Is there any reason to keep the reference active in between runs?

You could use the 'Execution State changed' event for initializing and uninitializing the refs.

Ton

[Murugan]

Yes. During edit time, as I add and remove controls, I am keeping track of all the controls as XML. This XML is being exchanged with external code (written in C) to make things happen in software outside of LabVIEW. Because I am keeping a persistent link between LabVIEW (in either edit or run time) and the outside software, and they both make use of common data related to the XControls, I have to keep it alive somehow. Since that common data is in XML, I could also just keep writing to/reading from a common file, but would rather just keep it alive in memory the entire time. Running a background daemon in LabVIEW that keeps that functional global active does the trick.

Eventually, I'd like to migrate many of these functions to external software running as a service, so that the XControls just make the appropriate function calls and LabVIEW handles very little of the functionality/data persistence itself. Even in this case, though, I might still have to keep a reference alive! I don't know how LabVIEW interacts with services.

[Rolf Kalbermatter]

Eventually, I'd like to migrate many of these functions to external software running as a service, so that the XControls just make the appropriate function calls and LabVIEW handles very little of the functionality/data persistence itself. Even in this case, though, I might still have to keep a reference alive! I don't know how LabVIEW interacts with services.

It doesn't other than you implement it. For LabVIEW a service is just another process so to access a service you have to provide a means of interapplication communication such as TCP/IP, shared memory, even DCOM, or whatever else you can come up with. My preference is clearly TCP/IP as it is the most platform independant interapplication communication channel I know of and also has the benefit of inherent remote access ability without compilicated RPC setup and initialization.

You hit it on the head, that was the problem, and I fixed it. XControls are little reentrant VIs that run as soon as the control is dropped on to a VI in edit time. Because there is a strange interplay going on between some things being in edit time and others in run time, I can see how LabVIEW might think that all callers to a functional global VI have been closed and clean up the references.

Actually you are probably misunderstanding something here. LabVIEW does not do reference counting on refnums based on VIs storing such a refnum. It couldn't really do that anyhow since a refnum is just a number that can be stored in many different formats that do not necessarily have to be refnums at some point.

LabVIEW disposes a refnum as soon as the top level VI in whose hierarchy the refnum was "created" goes idle, independant how many times you stored that refnum in global VIs, global variables, locals, shift registers or whatever.

[Murugan]

Actually you are probably misunderstanding something here. LabVIEW does not do reference counting on refnums based on VIs storing such a refnum. It couldn't really do that anyhow since a refnum is just a number that can be stored in many different formats that do not necessarily have to be refnums at some point.

LabVIEW disposes a refnum as soon as the top level VI in whose hierarchy the refnum was "created" goes idle, independant how many times you stored that refnum in global VIs, global variables, locals, shift registers or whatever.

I see. Well, the DOM Document object is instantiated inside the functional global and the reference is also held there on a shift register. Before, I was only calling that functional global from the XControls, which I suppose would be the "top level" VI in that case. Anyhow, once I initialize/shutdown that functional global from a different top level persistent VI (an event-driven state machine), it remains a valid resource as long as that VI is running. XControl VIs may not be reliable as "top level" VIs in this case because the state of those VIs and the XControls seems a little hazy.

I may have misspoke rather than misunderstood. If we're talking about "resources" rather than "refnums", my earlier description might have been more valid. That refnum remained in the functional global, and the number was always the same, which is something I checked earlier in my debugging. Obviously, it was the actual resource that the refnum was referring to that was disposed. Is that more correct? I don't always have my semantics in order.

[Rolf Kalbermatter]

I may have misspoke rather than misunderstood. If we're talking about "resources" rather than "refnums", my earlier description might have been more valid. That refnum remained in the functional global, and the number was always the same, which is something I checked earlier in my debugging. Obviously, it was the actual resource that the refnum was referring to that was disposed. Is that more correct? I don't always have my semantics in order.

The refnum is clearly disposed of and also disposes of the object. The refnum can then be reused for a different resource since its numeric value is really a 16 bit magic identifier and a 16 bit index into an array of resource pointers.