Jump to content

Cannot move or delete folder while LabVIEW is open


Recommended Posts

I remember reading something about this a while back but cant seem to dig is up with the search....

I'm running into an issue whereby browsing to a file in a LabVIEW path control seems to stop me from deleting that folder from any other part of my program until (a) LabVIEW is closed, or (b) I browse to a new path with the control in question.

As I said, I remember reading something, somewhere about the fact that LabVIEW keeps its current directory open (and therefore undeleteable) but I guess what I really need to do is point LabVIEW to a different current folder so I can delete the folder in question.

Any ideas?

PS. If it helps, my use case is this:

1. User has a data folder with a database file and a whole bunch of subfolders containing data thats too large for me to want to put in a DB record (such as hi-res images).

2. A User picks one of the files within the folder hierarchy to display in LabVIEW.... file is openned (file is also closed afterwards) and image data is displayed in a picture control.

3. User now decides that they want to move this entire dataset do wants to delete the database file and all associated content.

4. the LabVIEW move file/folder VI generates an error because it does not have permission to move the file

5. Trying to move the file in explorer also fails until LabVIEW either has a path control value change (using the browse button), or LabVIEW exited.

Link to comment

What really annoys me is when LV grabs onto files which were opened by completely separate applications. Examples I remember are MP3 or AVI files which I opened with Media Player Classic (by double clicking them in an Explorer window) and then for some reason LV opened one or more handles to them, thus preventing their deletion (I saw it's LV by using a third party program and by the fact that I can delete them immediately after I close LV).

The main problem is that I can't reproduce this reliably. I have no idea what's causing it. AQ, is it worth reporting such a thing?

Link to comment

What really annoys me is when LV grabs onto files which were opened by completely separate applications. Examples I remember are MP3 or AVI files which I opened with Media Player Classic (by double clicking them in an Explorer window) and then for some reason LV opened one or more handles to them, thus preventing their deletion (I saw it's LV by using a third party program and by the fact that I can delete them immediately after I close LV).

Glad someone else has seen this, I thought I was going insane when this was happening! :wacko:

Link to comment

Any details on that (when was it, CAR #)?

"

From my post of 3 Dec 2008

...

46949

Since that number looks funny it was given to me on SR# 1290801.

This is supposed to document an issue where LV does not always close files when it returns to the splash screen. I have to close LV completely before I can delete the directory where I was working. The note from the PSE passed to me from the AE was;

1- The PSE said the root cause of this behavior is due to Windows:

"Windows is updating the application's working directory when the file dialog is called. This can be easily tested by opening another VI/ project at a different path and then rename/move the original project (which should work). "

...

"

Ben

Link to comment

Here is my solution to this frequent annoyance.

1- The PSE said the root cause of this behavior is due to Windows:

"Windows is updating the application's working directory when the file dialog is called. This can be easily tested by opening another VI/ project at a different path and then rename/move the original project (which should work). "

While it may be the windows api lock that is preventing the folder from being deleted, I think the root of the problem is how the LV code uses the api. Think about what would happen if windows did allow a working directory to be deleted out from under an application. Every time the application reads or writes from the working directory the application would have to first check to make sure the directory exists. I don't think that's a very good solution.

It's not terribly difficult to store the current working directory in a variable and set the working directory to something like the root Labview folder. When the user initiates an action that uses the working directory such as the Open File dialog box, retrieve the previous working directory from the variable and use the windows api to set the working directory before calling the open dialog. Or better yet, don't use the OS working directory at all as part of the UI.

Link to comment

The other issue with files being locked by LabVIEW that another application opened I'm flabbergasted. Never saw that happen so far.

It happens occasionally, but the only way to notice it is to try to move or delete the file which is locked, so you won't notice it if you don't do that. The main problem is that I have no idea what's causing it. This is on Win XP SP3, LV 2009. I think it also happened with LV 7.0, but I'm not sure.

Link to comment

It happens occasionally, but the only way to notice it is to try to move or delete the file which is locked, so you won't notice it if you don't do that. The main problem is that I have no idea what's causing it. This is on Win XP SP3, LV 2009. I think it also happened with LV 7.0, but I'm not sure.

I'm on Win XP SP3 but don't have 2009 installed yet on my main machine which I use to work mostly. And I may not really use the applications where you see that. However I have frequently many applications open and also work regularly in Explorer to move files around, but if I had problems with files appearing locked they were either executables running (Windows allows renaming them though, so you can rename it and place a different executable under the old name although that could crash badly if the paging kicks in), directories locked by the SetCurrentDirectory() issue in the Common File Dialog or DLLs that are still opened in LabVIEW despite me having closed the VI that called them. Sigh!

Link to comment

Rolf, I assume that if anyone would know, you would - the only file type I can remember this locking happening to with reasonable certainty is an .avi file. Is it possible that Explorer somehow sent the open command to LV as well because the extension had "vi" in it?

I'm assuming not, because my understand was that the extensions are explicitly recognized using CLSIDs, but it's a guess.

Link to comment

Rolf, I assume that if anyone would know, you would - the only file type I can remember this locking happening to with reasonable certainty is an .avi file. Is it possible that Explorer somehow sent the open command to LV as well because the extension had "vi" in it?

I'm assuming not, because my understand was that the extensions are explicitly recognized using CLSIDs, but it's a guess.

Well the CLSID isn't the primary mechanisme really to determine what application to open for a file type. It can come into play but the normal path is that the key in the registry matching the file extension is queried and that is usually an alias to another key that contains the actual information how to launch the according application. The primary key can also contain optional information such as the list of program IDs that can cope with that file and also CLSIDs for applications that should be used to handle the file but this last one is not the normal operation for most file types.

A agree that the avi and vi extension have some similarity but this would mean that explorer has gone bad when parsing the file extension AND that LabVIEW somehow holds on to filehandles for files it was not able to handle and simply refused them. Quite a combination of unlikely coincidences.

Link to comment
  • 1 year later...
  • 2 years later...
Calling the SetCurrentDirectory() Windows API with a path you do not mind to be locked.

Uh...can anybody tell me how to set up a CLFN to do this? I've done very little work with calling DLLs from LV, and I can't figure out what type to map the BOOL return value to. :unsure:

 

Edit: Never mind, I found <labview>examplesdlldata passingCall Native Code.llb

Edited by Stobber
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.