I'm having some weird behavior with a COM DLL that's loaded from an EXE file. In previous versions of Windows, if I would call GetOpenFileName / GetSaveFileName (We use MFC so we use CFileDialog) on both the EXE or the DLL, the directory in which the dialog started would be the same. However, in Windows 7 we get some weird behavior where the directory used in the EXE does not appear to propagate over to the COM DLL. Because of a few bad design choices years before I started working here, some of the logic is located in the exe, and some in the DLL, and thus do some dialogs open a CFileDialog from the dll, and others in the exe. This is annoying, but I would expect the behavior to be similar. Anyone experienced this before, and does anyone have an idea on how to solve this without having to subclass the dialog and handle initial directory selection myself? Toolmaker

CFileDialog uses a OPENFILENAME struct, and we initialize it in both all instances to the same directory. However, the Windows 7 default behavior is to open in the last opened directory when the initial directory is equivalent to the first used initial directory.

If I open a file in the executable, go to another directory and open the file and then attempt to open another file, it starts up in the last used dir(Expected behavior). If I now open a file via a routine in the DLL, it starts in initial dir again(unwanted behavior).

*bump*