keeping .net refnum alive

[baldrik]

Hi all,

I am having trouble keeping a .net refnum alive. The vi that calls the constructor is dynamically launched and LabView appears to be collecting garbage and killing the refnum when the dynamically launched VI is done, though the caller/launcher VI IS still running. From reading the forums it appears that the reference should stay alive in the project context (still not sure exactly what that means), when any of the project VI's are still running.

The dynamic VI handles configuration of photon detectors in our experiments, the main VI needs to continue processing events while the config front panel is open, so we can set up our circuits.

Am I launching the dynamic VI incorrectly? Is there a way to keep the .net refnum alive?

Any light on the problem would be appreciated.

I am using windows LV 8.5

baldrik.

Message Edited by baldrik on 10-17-2007 01:48 AM

[Lycangeek]

You are correct in your understanding - The .NET refnum is not closed until either (a) it is explicitly closed by the LV diagram or (b) the Project Context is idle. What is a context? It is kinda hard to describe as it is an internal thing to LV...generally it maps 1:1 to either LV itself (assuming you aren't using any projects) or 1:1 to each project you have open. Thus if you have two VIs running out of the same project, both must go idle. If there is a 3rd running but it is actually in a different project, then it isn't considered when shutting down the first two.

The kicker is the dynamic call - I don't know whether that might be in its own context (and of course, there may be a bug). You can verify this by creating a simple test program that creates a simple System.Object object or something with two VIs...then try calling it directly and then dynamically.

[baldrik]

It does appear to be the fact that the VI is dynamically launched, earlier in the dev cycle it was called as a subvi and there were no issues with the refnum. Both VI's are in the same project. For now I just keep the dynamic one running and hide and reveal it as necessary. This is not ideal but when hidden the vi should be idle waiting on UI events and hopefully not consuming cpu cycles.

It would appear that the launched VI is in its own context.

baldrik.