"Flatten to String"/"Set Property Value" corrupts an array of ActiveX objects?!

[Nickster]

I am trying to pass an array of ActiveX objects to a dynamically loaded VI. To do this, I use "Flatten to String" in tandem with the "Set Property Value" invoke node.

After some de-bugging, I have realized that LabVIEW is mangling my array of ActiveX objects. The objects are no longer valid when they arrive in the dynamically loaded VI. Is this an expected result, or a bug?

I would like some sort of fix that still involves a dynamically loaded VI. I can use a Call By Reference node, and that in fact works, but it is less ideal than using a dynamically loaded VI, particularly since I want the calling VI to close without waiting for the subVI to stop executing. (The calling VI is an initialization/splash screen VI that calls the main application interface. I'd rather not have it sitting around in RAM while the main application does its thing.)

Nick

[Nickster]

One extra note. I also tried using the "Set Control Value [Variant]" invoke node. This also incorrectly passes the array of ActiveX objects.

Nick

[Nickster]

I have worked around the problem by using a global. This is acceptable because I have a relatively small array of objects, so there won't be too much overhead involved. However, I'm still curious if the problem I've encountered is a bug, known problem, expected result, or what. If anyone out there knows the answer, I'd be glad to read it.

Nick

[AESulzer]

Nick,

I tried to replicate the failure, but couldn't. I was able to pass an array of ActiveX references to a dynamically loaded subVI just fine using the the Set Control Value [Variant] method (without Flatten to String). Is it possible that you're using an earlier verison of LabVIEW? I did this experimentation on LabVIEW 7.1.

Regards,

[Nickster]

To answer your question: I'm running LV 7.0 on WinXP with a P4 processor.

The array is sized correctly when it's passed to the subVI. It's just that the objects are somehow invalid. Passing them through a wired terminal seems to be the only way to go. It occurs to me that I should try sending a single object (not an array) just to see if it works.

Thanks,
Nick

[Nickster]

Jeez, I'm sorry this has become such a long, drawn-out monologue of a thread. However, I feel it's good to bring closure to threads. After all, this is a *help* forum.

I believe I've traced the problem. The objects become invalid not because of anything the Set Property Value node does, but rather because I close the very VI that creates the objects.

My usual application initialization scheme involves a modal VI that doubles as my splash screen. This locks everything up nicely so that the user knows the application is starting up but at the same time can't interact with anything to screw up the delicate initialization process. This initializing VI dynamically does any initialization processes, loads the main application VI, passes a couple values using Set Property Value (usually a VISA ref or something), opens the front panel of the main app, and runs it. I set "Wait until done" on the Run node to false and then close the initializing VI. The main app VI keeps on running.

But for reasons I'm not sure I fully understand, when working with ActiveX objects, closing the VI that created the objects (the initializing VI) invalidates them - even though they've already been handed off to another VI. There's your moral. I'm not aware of any other data types that this happens with.

Nick

[AESulzer]

Nick,

That's exactly right! My apologies for missing that -- I didn't encounter it in my experimentation because I still had the calling VI open when the reference was passed. In LabVIEW, when a VI concludes execution, all open references that were opened by the VI are closed as a safety feature so that references are no left dangling in the background. In your situation, however, this safegaurd is causing problems. There's no way to turn the "feature" off, but one suggestion is to have a seperate VI running in the background that manages all of your references -- the front panel could even be hidden.

Anyway, my apologies again for the oversight before, but I'm happy that we got things figured out. Best of luck in your development!

[Lycangeek]

Just to clarify what AESulzer said, it isn't that when the VI that created the reference is closed that LV closes the reference, but when the top level VI stops. Here is how it works...

WARNING WARNING WARNING - This is a behavior that is based on the way LV code works currently. No commitment that future releases of LV will clean up leftover references in the exact same way - WARNING WARNING WARNING

Sorry - gotta say that. I don't see it changing in the near future but just want to cover my bases. Anyway, back to the story...

When a VI opens a refnum based item (such as ActiveX, .NET, files, etc), we register a cleanup procedure in the top level VI of that system (VI A calls VI B which calls VI C which opens the reference - then the cleanup waits for VI A to stop).

If you then manually close the reference (which you should do, especially if you are creating references over and over again in a long running application), we unregister the cleanup for that reference. However, if you don't, when VI A stops running, the cleanup procedure goes through and closes the references for you. Thus in a general application (such as the A, B, C example above), the references are closed when the application stops.

In your case, I am guessing that your splash screen is the top level VI when you are openning your references. Thus when you switch off to a different execution stack of VIs, the splash screen stops and we close the references.