21 replies to this topic

[Shaun Hayward]

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.

[Ton Plomp]

NI claims this is caused by Windows. The OS has for every application an 'active folder'. Which is locked until the app is closed. It might help to open a file in another folder (without a browse dialog).

Ton

[Aristos Queue]

It might help to open a file in another folder (without a browse dialog).

Yes, that does indeed help. Whatever the last directory you opened or saved a VI into, that's the directory LV holds locked. Open or save into any other directory to move the lock. Or close LV.

[Yair]

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?

[jgcode]

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!

[Aristos Queue]

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?

I've never dug into it... it never bothered me. Might be easy to fix if someone tried to fix it. So, yeah, go ahead and report it.

[neBulus]

I've never dug into it... it never bothered me. Might be easy to fix if someone tried to fix it. So, yeah, go ahead and report it.

I reported that bug and gave up trying to fight for it being a bug since other software (other than LV) does not do that. If you get the fixed great.

Ben

[PJM_labview]

Adding my 2c here.

I think I have experienced a lot more locks in LabVIEW 2009 than in previous LabVIEW version. I have a utility allowing me to bypass the lock and erase the file (or folder), unfortunately this is no longer working well (if at all) with LabVIEW 2009 locks.

PJM

[Shaun Hayward]

Is there any way to programatically point LabVIEW's lock elsewhere (ie without poping up a file browse dialog)?

[Yair]

I reported that bug

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

[neBulus]

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

[Yair]

OK, that's the original issue, NOT the one I was talking about. I guess it needs to be reported separately.

[Daklu]

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.

[rolfk]

Is there any way to programatically point LabVIEW's lock elsewhere (ie without poping up a file browse dialog)?

Calling the SetCurrentDirectory() Windows API with a path you do not mind to be locked. The issue is that the Common File Dialog function in Windows sets this to the current path whenever it is dismissed with an OK click. So yes it is really a Windows issue. It happens with other applications too, that use the Common File Dialog but you rarely run into that issue there, at least I don't.

The actual API seems to have a flag OFN_NOCHANGEDIR that prevents Windows from changing the current directory if the user browses to a different directory during the dialog, but it is not supported before Vista. So NI still would have to inmplement a workaround around the Common File Dialog call, which admittedly shouldn't be difficult, but it may have implications in areas nobody is thinking about at the moment.

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

[jgcode]

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

Well LabVIEW locked files that where in my Recycle Bin today... weird.

[crelf]

Calling the SetCurrentDirectory() Windows API with a path you do not mind to be locked.

IMHO: There's a post that deserves a kudos!

[Yair]

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.

[rolfk]

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!

[Yair]

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.

[rolfk]

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.