.NET Reference doesn't load automatically from LabVIEW VI

[dug9000]

By .NET UI control, I mean a user-interface control that is written in .NET that displays a UI on a LabVIEW panel using the LabVIEW .NET container control. Just using a .NET assembly from a VI is different than what I'm asking about.

If you are not using a .NET UI control on the LabVIEW panel then the problem you are seeing is not due to the issue I was thinking of. Please let me know either way.

Be aware that .NET assemblies cannot be individually unloaded. This is how .NET works, the only way to unload an assembly is to unload the entire app domain in which it resides which likely only happens in LabVIEW if all references to all .NET assemblies are closed.

Hope this helps,

-Doug

[Terry Mac]

It is a .Net UI control I’m developing and it is created at the start of the application and the same instance is used until the application exits, I can see that it would be a problem to instantiate the same assembly a number of times on the same reference, but I don’t need to do this.

Terry Mac

[dug9000]

Hi Terry,

You might be encoutering a known issue related to running a VI with a .NET UI control on it from TestStand using the LabVIEW development evironment, though the behavior you are seeing is not exactly the one we would expect for this issue. Have you tried running your VI using the LabVIEW run-time engine instead of the development environment? In TestStand, you can change the adapter configuration options for the LabVIEW adapter to use the LabVIEW run-time instead of the development environment. If the problem goes away when using the run-time engine then it might be related to the known issue.

Also, if you can attach an example VI which reproduces this problem, preferrably one that uses a standard .NET UI control rather than a custom one, that would be very helpful in determining the cause of this problem.

Also please let us know which version of TestStand and LabVIEW you are using.

Thanks,

-Doug

[Terry Mac]

I’m using version 8.5.1

Attached is the code for a simplified user interface

The code generates two .Net objects UserIF and UserForm

All the UserIF object does is create and show an instance of the UserForm (so effectively it is creating and Form object with a limited number of methods)

What I’m finding within Vi is I can create, close and destroy (by assigning to “Close Reference”) an instance of the UserIF object but when I try to do the same with the UserForm object Vi throws an exception when I close it. It needs to be closed as Vi does not unload it until the application is exited.

I don’t have a problem with this all it means is that I have to create a stop event to close the object. I now understand why you we’re asking if I was creating a .Net UI (based on a form) or just a .Net object. I am creating the .Net UI but I’ve encapsulated it within an object (so I’ve got around the problem without knowing it). I normally create .Net components like this anyway as it enables me to limit the methods and attributes that the consuming will have access to.

At the moment I have a Stop button on my Vi that creates my stop event, what I would like to know is how to create an event when the “Abort Button” on the Vi form is pressed so I can clean up the objects when this button is pressed.

Terry Mac

[D_Biel]

Terry,

Unfortunately, there is no way to handle the Abort Execution event. The abort execution is like an emergency stop. You can think of a big red emergency stop button on some heavy machinery. If you hit that button, you would want it to stop in its tracks and not worry about proper shut down and clean up procedure. In the same light, LabVIEW terminates the execution immediately. Therefore, there is no way to run any code after the abort button is pressed. The abort button is just to help you get out of situations like infinite loops or deadlocks. Using the event from the stop button would be the best way to handle this. If you are concerned about a user pressing the abort button and not going through the cleanup phase, then you can hide the toolbar so that the abort button is not available to the user.

[dug9000]

The example didn't get attached, but this no longer sounds like what I thought you meant. You are displaying a .NET Form. This is different than what I meant which was showing a .NET UI control on a LabVIEW (not .NET) panel. This is likely unrelated to the known issue I was referring to.

-Doug