GetOpenFilename api call in Windows 7 won't allow direct access to My Documents

Question

In many of my Access (2002) programs I use the GetOpenFileNameA and GetSaveFileNameA functions from comdlg32.dll. I often set the initial directory to the user's My Documents folder (using calls to SHGetSpecialFolderLocation and SHGetPathFromIDListA from shell32). This all works fine under Windows XP.

However, I recently switched to Windows 7 as my development environment and have been getting the following error message:

You can’t open this location using this program. Please try a different location.

The function I use to get the My Documents location is returning the correct folder. However, even if I hard code that directory location into the GetOpenFileNameA call, I still get the error.

I came across this post: http://social.msdn.microsoft.com/Forums/en-US/windowsuidevelopment/thread/3391f1dd-25b0-4102-9d5c-58309cc72c9d but, even adapting it to work with Access instead of Excel, I had no luck.

EDIT: Suddenly this is no longer a problem for me. I suspect a windows update went out addressing this issue. Does anyone know if that's true or not?

EDIT: It turns out this is still a problem. Also, in case it helps in the troubleshooting I have found that I get this error message for any of the special folder locations (My Music, My Documents, etc). Also, if I change the location of the My Music folder to, say, C:\Test then I get this message when I try to open the folder C:\Test, while the folder C:\Users\Mike\Music (the original My Music location) opens without a hitch.

Answer 1

Windows 7 adds the concept of a "library", which is basically a virtual folder that includes the contents of at least two actual subdirectories. One place it uses the library is the "My Documents" folder, which (at least by default) is a library that includes both the user's documents directory ("c:\users\whoever\documents") and the public documents directory (C:\users\public\documents").

As such, the basic approach you're using simply can't work -- there is no path that denotes the Documents folder. The documents folder needs to be specified by a PIDL, not a path.

Edit: It's not clear what's going on if you can't open C:\users\user\Documents. A quick test in C++ works fine using code like:

OPENFILENAME data = {0};
wchar_t filename[256] = {0};

data.lpstrInitialDir = L"C:\\users\\jerry\\documents";
data.lStructSize = sizeof(data);
data.lpstrFile = filename;
data.nMaxFile = sizeof(filename);

GetOpenFileName(&data);

OTOH, there's no real need to specify the initial path -- the Documents folder is the default anyway.

Answer 2

The link I posted in my original question (http://social.msdn.microsoft.com/Forums/en-US/windowsuidevelopment/thread/3391f1dd-25b0-4102-9d5c-58309cc72c9d) held the answer after all. I'll summarize things here. To fix this behavior, you need to do away with the STRIPFOLDERBIT flag in the shell compatibility registry entry for all affected programs.

Keep in mind (and this is what tripped me up for so long) that 32-bit programs have entries in a special registry section if you have 64-bit windows. Here's the quick and dirty:

Rename STRIPFOLDERBIT to xSTRIPFOLDERBIT for the following keys (as applicable):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\excel.exe HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\msaccess.exe HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\excel.exe HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\msaccess.exe