VB6 Common Dialog Control File Open does not give correct folder

[Arnoutdv]

I have an application which can be used for different data environments on a single PC.
The application is therefor placed in different folders.

Example:
X:\Software\Radio\Software
X:\Software\Radio\Data
X:\Software\Radio\Data\User\[username]\Reports

X:\Software\TV\Software
X:\Software\TV\Data
X:\Software\TV\Data\User\[username]\Reports

In the application when you choose open/save the CommonDialog is used for selecting an in/output file.
The InitDir property of the CommonDialog is used to jump to the correct location.
Sometime when using the TV environment the statement CD.InitDir = "X:\Software\TV\Data\User\Arnoutdv\Reports" seems to be ignored and the CD opens in "X:\Software\Radio\Data\User\Arnoutdv\Reports"

I've placed logging statements in the Open/Save routines to show the initial path variable and the content of CD.InitDir, even when they both show the correct values the CD opens in the incorrect folder.
It does not happen all of time time and the OS varies from W7 to W10

For my life I can not get it to simulate from the IDE (where I can also choose from multiple data environments).

I found a similar thread on StackOverflow and I've read some forum posts in which is stated that the CommonDialog persists it's own "recent" folders per application somewhere in the registry
Sometimes the CD.InitDir is ignored and a folder from it's "recent used folder" is used for the initial folder.

Thread on vbForums discussing the same problem.

Has anyone ever encountered the same and found a workaround?

[Arnoutdv]

A discussion on social.msdn.microsoft.com/Forums
Suggestions:

• using the IFileDialog (there are samples in the CodeBank, but needs a serious code rewrite)
  

  A better approach might be to use the IFileDialog interface on Vista and 7.

• specify a filename also for .ShowOpen (annoying to see an already selected filetitle in an Open dialog)
  

  You should be able to put the full path in the lpstrFile field of the OPENFILENAME struct (and leave lpstrInitialDir empty). This is generally what is used in the "Save As" scenario for instance, where the dialog starts in the same folder as the item you are "save as"ing exists. You'll probably need to supply a filename too though (which will appear in the filename box).

• delete some registry settings (effect on other applications??)
  

  delete the "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRULeg acy" and "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU" keys before setting the m_ofn.lpstrInitialDir structure members

[Arnoutdv]

Found an article on MSDN:

The dialog box uses the current directory for the calling process as the initial directory from which to display files and directories. Use the GetCurrentDirectory and SetCurrentDirectory functions to get and change the current directory of a process. To specify a different initial directory without changing your current directory, use the lpstrInitialDir member to specify the name of a directory. The dialog box automatically changes your current directory when the user selects a different drive or directory. To prevent the dialog box from changing your current directory, set the OFN_NOCHANGEDIR flag. This flag does not prevent the user from changing directories to find a file.

Have to check whether I use OFN_NOCHANGEDIR mask in the Flags property.
Also setting the CurrentDirectory to the desired "reports" folder might be worth to try, though I don't like changing things like the CurrentDirectory, but this can be restored to the previous folder after showing the CommonDialog.

[westconn1]

do you have full permissions for all the folders?
if some folder is virtualized it may be ignored as initial directory

[Arnoutdv]

I have full permissions and the folders are not virtualized.

[Arnoutdv]

I tested:
SetCurrentDirectory to the correct reports folder: no effect
Specify an existing file from the reports folder as the FileName: filetitle shown in text field, but still in the incorrect directory.

I'll give some time and if no working solution can be found then I try the IFileDialog implementation from the CodeBank,
Maybe write a simple wrapper which mimics the CommonDialog interface to reduce number of code changes.

[dilettante]

Without evidence that IFileDialog wasn't altered in the same way for the same reason it may not be worth pursuing.

If you want full control you could take full control. Build your own file-picker dialog Form. You can either wrap the old VB6 intrinsic controls (Drive-, Dir-, and FileListBox) or create a fancier one based upon a ListView with some other controls and a little enumeration logic to populate the ListView.

With some effort you can host a Shell ListView within a WebBrowser control. Some of the effort comes from suppressing the normal actions within this control.

[Tanner_H]

Hi Arnoutdv. You might try the fix suggested at the end of this vbcity thread:

I think it is a bug in InitDir. I have solved it by inserting "ComDlg1.FileName = vbNullString" before you set InitDir.

[Arnoutdv]

@dilettante, that's quite an undertaking. I also tried CommonDialog implementations from other other suppliers (like the one from CodeJock), but they are all wrappers around the CommonDialog API, so the same problem.

@Tanner_H: I have found that reference a while ago, doesn't solve the issue.

[gibra]

I'm not able to reproduce this issue, can you zip a sample project?
However if you try to set

InitDir = vbNullString
next
InitDir = yourPath & Chr$(0)

something changes?

[Arnoutdv]

I did all test again and it seems that the method of setting the .FileName to an existing file in the desired directory does work, but I had to set InitDir = vbNullString.
At last it works, with a small annoyance of having a pre-selected file name when doing a ShowOpen.

[Tanner_H]

One of the nice things about using API wrappers around CommonDialog (besides the obvious benefits like Unicode, etc), is that you get a much better idea of what flags and parameters are explicitly filled, which can really help when narrowing down these issues.

This StackOverflow thread suggests that the behavior is intentional, and a number of other workarounds are provided. Some suggest that the behavior differs between the old XP-style and newer Vista+ implementations, with different fixes required for each.

[Arnoutdv]

@Gibra, it's very hard to replicate. It just happens once in while
By coincidence I had access to PC today which had this problem with same application placed in 2 different folder, which each has it own document folder.
App 1 was working correctly, but App 2 was showing the directory set by App 1.
I could try all kind of solutions by replacing App 2 on this PC.

@Tanner, The behavior is indeed by design (since W7??) and I'm not sure they do something different then I do with last method specified:
Set the .FileName to a file in the needed folder and set the InitDir to vbNullString

[fafalone]

If you use IFileDialog you have a number of options. You have direct access to control the last opened path-- I'm not sure if it works this way in the older dialog, but the default directory is only used if there's none stored from the last use (see details here).
You can also always manually force the initial folder opened with .SetFolder (different from .SetDefaultFolder as per above).

[Arnoutdv]

I will certainly check the IFileDialog, our software is only used on W7 and up, WinXP/Vista not supported.

[pekko]

In you app before using Common Dialog Control delete proper value from

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\FirstFolder

http://www.programmershare.com/2810931/