File dialog should not block file operations

[shb]

When a file is opened with the file open dialog of LabVIEW, the containing folder can not be moved, even if the file is closed. It is only possible when a file in an other folder is opened.

Not only moving is not possible, but also moving, renaming and ejecting the containing drive.

The folder should definitely not be locked by the dialog after it is closed!

This issue still exists in LabVIEW 2010 SP1.

[altenbach]

This sounds more like a bug report than an idea for a new LabVIEW feature.

Do you have some simple code that demonstrates the problem? What OSs have you tried?

[GregR]

I can confirm this is a known behavior. The problem is it is also defined Windows behavior. The problem is that the Windows file dialog sets the current working directory to the directory you choose a file from. Since that directory is now the working directory of a running process, it can't be renamed, moved, deleted or apparently ejected. We have been reluctant to override this behavior of the OS because that might cause some other problem on some version of Windows that we might not detect. If this gets enough votes, maybe we'll do it anyway.

Workarounds include using the file dialog to pick a file from a different directory or programmatically setting the working directory after presenting the user with a file dialog. 

[shb]

@altenbach

Where else should I send a bug report? From the "Product Suggestion Center" I am redirected to the idea exchange when I select LabVIEW as Product.

instruction for reproducing:

• create a new folder
• create a VI in this folder
• open the VI inLabVIEW with the file open dialog (ctrl-O)
• close the VI
• rename the folder, this does not work

@GregR

Thanks for your feedback.

You are right, also Microsoft Office programms seems to do this. I am surprised that I did not realize this until today. It probably is because I close the office programs when done. Because LabVIEW has a long start up time with all the plugins, I do not close it for editing a different VI.

But notepad does not do it. This topic is confusing.

[altenbach]

Bug reports should typically be reported and discussed in the LabVIEW forum. After some discussion and feedback, it will end in a trackable CAR #. In addition, a link should be provided in the monthly bugs thread to alert NI to a bug discussion. (If you have SSP, you can contact NI directly, of course).

I agree, there might sometimes be a fine line between a "product suggestion" and a "bug report".

"Design LabVIEW to never crash" is an utopian product suggestions, while "If I do A followed by B in the attached example, LabVIEW 7.1 crashes with error XYZ" is a bug report. So if you report and discuss it first in the discussion forum, the collective wisdom of all active LabVIEW users is leveraged to decide if it is a LabVIEW bug, an OS bug, expected behavior, a misunderstanding of the correct functionality, a combination of all or something else entirely. Even if it is a bug, somebody might find a good workaround. 

(Notepad is extremely primitive and lets you open files that are in use. I don't think we want that with LabVIEW.)

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.