File Dialog bug?

[elset191]

Either I don't know what I'm doing or the File DIalog doesn't know what it's doing.  To see what I am seeing, run the attached snippet.  After the dialog pops up, browse to a different folder, ie, Desktop.  Then hit OK.  What I'd expect is an output filepath to Desktop\Data Report.xls.  But instead, it opens the folder you came from initially.  If you type into the file name control and hit OK it returns the expected path.  It does not seem aware that there is a default path already entered.

Am I missing something?

[billko]

---

@elset191 wrote:

Either I don't know what I'm doing or the File DIalog doesn't know what it's doing.  To see what I am seeing, run the attached snippet.  After the dialog pops up, browse to a different folder, ie, Desktop.  Then hit OK.  What I'd expect is an output filepath to Desktop\Data Report.xls.  But instead, it opens the folder you came from initially.  If you type into the file name control and hit OK it returns the expected path.  It does not seem aware that there is a default path already entered.

Am I missing something?

---

I think you chose an unfortunate target for your second one.  My first path defaulted to my LabVIEW Data path - but Desktop contains my profile folder which contains that folder, so it does what you said.  Try choosing a different second target - like the root directory - and you will see it behaves correctly.

Incidentally, I see that with file dialog boxes not gnerated by LabVIEW, too.  So I guess you know what you are doing AND File Dialog box knows what it is doing, too.  😉

[RavensFan]

What version of Windows are you running?

Besides Desktop, what other folders does this happen to?

I'm on Win7 and I see strange behavior if I pick the desktop folder from the highest level of the hierarchy on the left hand tree.  It winds up opening a folder with a list of "special" folders such as AppData Contacts Desktop Documents Downloads  MyMusic MyPictures .......

If I pick the desktop that shows up in that window, or I pick the desktop that is deeper in the tree on the left hand naviagation window, then the File Dialog seems to properly close and has picked the true desktop location.

I really don't think this is a LabVIEW bug.  I think this is a Windows bug, or actually an "expected feature" since Microsoft has played around with the security features of Windows between the days of XP, and has a lot more "fake" paths, and aliased paths that sort of hide the true directories you are really trying to find.

It seems like it has created two desktop paths just to try to confuse us.

EDIT:  Rereading Bill's message above, I think he is talking about the same thing and his phrase of "Profile folder" is probably the name for the sort of second fake Desktop folder I'm stumbling on.

[elset191]

---

billko wrote:

I think you chose an unfortunate target for your second one.  My first path defaulted to my LabVIEW Data path - but Desktop contains my profile folder which contains that folder, so it does what you said.  Try choosing a different second target - like the root directory - and you will see it behaves correctly.

---

You're right about it behaving as expected when I go to a different folder.  And you're also right that the profile folder contans the Default LabVIEW Data directory. 

What I don't get is why the Profile directory is selected when you go from the data directory to the desktop.  This means pressing OK opens that directory instead of saying "OK, pick this file".  Having it selected makes some sense if there's not a default provided, because it means pressing OK straight away doesn' t return an empty path.  With a default path provided I'd argue that the behavior should not be the same.

It seems that the original path and second path don't particularly matter.  If the second target you get to contains the original target, the first OK press will open that folder, rather than selecting that path.

 At the very least this is undersirable (to me).  As Ravens said, I'd be inclined to point the finger at Windows on this one.  Anyway, I think I'm just going to leave the default path unwired, since it behaves more reasonably in that situation.

Also, I'm on Windows 7.

[JÞB]

set up the browse options

[QFang]

I find this annoying too.

I have a program that tracks the last used folder and I use that to set the "default" folder so that when I prompt the user, they will start in what should be a folder "close" to where they want to go.

I also provide a suggested "file name" based on time-date and some other parameters.

The intention is that the prompt opens and it works well if the user does not want to change the location (e.g. if they just hit "ok" or if they change the file name and then hit "ok") but if they either create a new sub-folder, or go back up one or more levels and then hit ok, the file is saved in the default folder (using the suggested file name).  The only work-around I found is to first change the folder, then, click on the "suggested file name", select a random character in the file name and "replace" it with the same character.. if you hit "OK" now, it will save in your selected folder with the suggested name.  (Similarily, if you compeltely replace the suggested name with a new name, that works too).

So for some reason it seems the path does not properly update as expected unless there is a value change event triggered on the file name....   Incredibly annoying.

[pbjohnso]

This bug still exists for Version 2022 Q3 (64-bit) on a window 10 machine.

Changing the folder path while having a default name, and then selecting OK goes up back one level from where you just changed the folder path...

I find this an annoyance, and have not looked for  a clean work around... but I figured I would let others know they are not going insane.