04-27-2010 08:35 PM
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.
Solved! Go to Solution.
05-03-2010 09:21 AM
Hi Synaesthesiac,
I searched our internal bug report database, and I didn't find anything I believe could be related to this. Have you noticed that this happens after something specific is changed in the XControl/XML? After the "Resource not found" error, you mentioned that some VI's continue to return the error while other VI's (like Read from XML File) use the DOM document reference correctly. Which VI's continue to return error 15? I'm also curious, have you found any way to recover from this error?
05-03-2010 05:34 PM
LaRisa,
It turns out that there is not a bug, necessarily. The problem stemmed from how LabVIEW automatically cleans up references for VIs that are no longer active. I was calling the functional global from the XControls in the Init and Uninit ability VIs. After creating and removing several copies of the XControl on my front panel, LabVIEW must have decided that I was no longer using the functional global VI and cleared out its references.
To fix this problem, I now initialize the functional global from a hidden "main" VI that runs as long as I have any XControls on the front panel. The trick was putting the functional global in to a calling tree that stays active rather than one that is more sporadic, such as the XControl VI calling tree.
I can understand why there was a problem, considering the unusual execution of XControls.
Thanks for following up, I hope this helps others when building XControls--they are really not so bad once you get used to their strange behavior.
05-04-2010 09:27 AM