Releasing a .dll that a VI holds

[jack@nz]

Hi guys, I have a dynamically opened sub-VI (opened by )

once it gets opened, it seems to "hog" on to a dll file (namely, LVWutil32)

and by hogging, I mean that if I try to delete the folder that contains this dll, I get an access denied exception,

and if I close that sub-VI, the exception goes away.

Now, what I would like to know is: how do I "close" sub-VI programmatically in labview, so I can remove the folder?

Cheers!!

[jack@nz]

I have already tried using the VI methods "abort" and "close FP"

neither of them allowed me to delete the folder.

So far it seems that the only way that works is clicking the "X" on the upper right hand corner of the front panel lol....

[GerdW]

Hi Jack,

why do you want to delete a folder when your subVI needs this folder??? In the next run you would receive error messages...

Why doesn't quit your subVI automatically? Why don't you copy the dll into the standard dll search path? Why are there so many more questions on your unusual dll usage?

There are cases, when an "Abort" will not do what it is intended to do (once I had this case with a broken serial port). So your best option probably is to click the "X"...

[jack@nz]

Lol, Gerard, I can see that I have left a lot of the details unexplained...

sorry about that, but I was hoping I won't turn people away with too much details

In short, I don't actually need that sub-vi once I close it, because I actually need to open a different one.

Anyway, the full picture is as followes:

My application works with a tester. Different hardware interfaces can be switched on the tester, for testing different products.

The application downloads different software packages, with respect to the fixture it sees.

The sub-vi is actually a part of the package, which gets executed after the package is donwloaded.

Now, when we change a fixture, I want to close that sub-vi, delete the unzipped package folder, 

so I can download the compatible software package.

That sub-vi is stopping me from deleting the not-needed-anymopre software package, unless I hit the "x" button.

I hope some one else can shad more light on me for this one !:

[Norbert_B]

I think there are several things we have to discuss/make clear here:

1. I have no DLL called LVWutil32.dll on my system. Windows file search did not result in any hit when using "lvwutil32" as search parameter. Where does this derive from? Where is it stored on your disk? How is it used in your code?

2. If loading a DLL, the OS attaches the DLL execution to the process of the calling application. Hence, the DLL will be attached to the process "LabVIEW.exe" (or "<applicationname>.exe"). As long as this process "lives", the OS can decide (or not) wether to deattach the DLL. Since LV is working very conservative with resources, DLLs are not likely to be unloaded until the process is shut down.

3. Referring to 2, there is a possible way to load and unload DLLs dynamically on purpose. See this link for information.

just my 5 cents,

Norbert

[jack@nz]

Guys, I have actually got a solution.

I turned the sub-IV into a queued-state machine.

And instead of executing the close.FP on the sub-VI,

I stacked an event to make the sub-VI to go the state-machine termination case, which executed the close.FP method on itself, after ending the while loop.

This method worked. I no longer got the LVWUtil32.dll access violation problem