Files still open during startup window display

[MWiehl]

After having closed changed VIs, I can see the startup window popping up. But when I try to change the name of the directory, where the closed files are in, Windows reports that this is not possible because an application still accesses this files. As soon as I close LabView completely, the rename process works fine. So why are this files still in use after I have closed them within in LV?

[chrisger]

Hi there

This happens because the directory is the "CurrentDirectory" of the LabVIEW application (i.e. that directory that is opened whenever you open a file dialog box to open or save a file) and therefor this directory is locked by the OS from being renamed or removed. To change the CurrentDirectory open a VI located in an other directory or create a blank vi and save that into an other directory.

Same with most other (windows) applications!

[MWiehl]

Thank you,

anyway, this should not happen, because I literally closed (!) the files, so there should not be any relation between the program and these files. By the way, I might be the same in other applications too, but this does not say that this will be normal in future. If you use text editors or internet browsers then you will see, that the program loads the data into memory and you can continue working on the harddisk until the program (or the user) wants to save the file. As soon as this happens, the software tries to save the file in the target directory. In this case any possible situation must be handled (e.g. the file was deleted during modification, the connection to the directory is lost e.g. in case of network drives, the file is write protected etc.). This should be the correct behaviour.

I recommend NI developers to correct this.

Anyway, thank you for the explanation.

Greetings,

M. Wiehl

[Ben · Accepted solution]

I call this a bug as well!

I reported it to support and recieved a CAR# 46949

Please note that CAR# is correct since this was reported ages ago. The last word I got in this BUG 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). "

---

Which do not agree with at all. So can anyone make a convincing aguement for it being or not being a bug?

Ben 

[Wiebe@CARYA]

Hmm. I thought this was a know bug. It has been like this since at least LV
7.1, and I suspect far before... I learned to live with it, never thought
about posting it as a bug (which it is).

Argument for being a bug: It is *very* anoying.

Argument for not being a bug: Windows causes it (it still is *very*
anoying).

Regards,

Wiebe.

[rolfk]

---

Ben wrote:

I call this a bug as well!

I reported it to support and recieved a CAR# 46949

Please note that CAR# is correct since this was reported ages ago. The last word I got in this BUG 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). "

---

Which do not agree with at all. So can anyone make a convincing aguement for it being or not being a bug?

Ben 

---

If it is a bug it is a Windows bug, but I doubt you can convince MS that this is so. The current directory manipulation of the Windows file dialog is a fact. That a directory that an applications current directory is pointing to is getting locked is one too. So where is the bug in LabVIEW? I can't see it. One could argue that setting LabVIEW to use its own file dialog should actually work around this bug

So LabVIEW even has a fix for this Windows bug.

Rolf Kalbermatter

Message Edited by rolfk on 02-11-2009 08:06 PM