Ok this is basically a rant, but maybe someone has a rationale...

With Win2000, the rules for the initial directory used by the common
dialogs (GetOpenFileName, GetSaveFileName) changed significantly.
Whereas previously, if you didn't specify a directory (or a filename),
it would use the current windows directory, it now remembers which
directory the last common dialog in your application used.

It doesn't take much thinking to realise this hopelessly breaks
applications that use open/save dialogs for various purposes, not just
for opening the primary document type. Whereas previously you could
use the OFN_NOCHANGEDIR flag for secondary-type open/save dialogs, or
manually set the current directory yourself as needed, now you have to
explicitly set the lpstrInitialDir member of the OFN structure. Well
that's not so bad, except that MFC doesn't allow you to set this
without creating your own CDocManager class and overriding
DoPromptFileName, which involves copying a significant chunk of code
from the MFC source just to add 3 lines:

TCHAR szCurDir[MAX_PATH];
GetCurrentDirectory(MAX_PATH, szCurDir);
dlgFile.m_ofn.lpstrInitialDir = szCurDir;

Which restores everything back to something resembling normality!

Now I could understand it (just) if the rule was changed such that the
dialogs would use the last directory chosen in a common open/save
dialog with the same filter, but not just ANY open/save dialog in your
application.

Now if someone knows a way to turn off this behaviour (ideally for a
single application, but for all is probably better than nothing), I'd
be most interested. I did read about a NoFileMRU registry setting,
but I'm not sure exactly where it goes and how it works.

I also figured that you could explicitly search the values under
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedMRU

for one that matches your application and delete it, but that's hardly
a pretty solution, or one that's likely to work in future versions of
Windows.

Anyway, interested if anyone else has had the same frustrations.

Dylan

You could try with OPENFILENAME_SIZE_VERSION_400
as lStructSize.

- Sten

"Dylan Nicholson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Ok this is basically a rant, but maybe someone has a rationale...
>
> With Win2000, the rules for the initial directory used by the common
> dialogs (GetOpenFileName, GetSaveFileName) changed significantly.
> Whereas previously, if you didn't specify a directory (or a filename),
> it would use the current windows directory, it now remembers which
> directory the last common dialog in your application used.
>
> It doesn't take much thinking to realise this hopelessly breaks
> applications that use open/save dialogs for various purposes, not just
> for opening the primary document type. Whereas previously you could
> use the OFN_NOCHANGEDIR flag for secondary-type open/save dialogs, or
> manually set the current directory yourself as needed, now you have to
> explicitly set the lpstrInitialDir member of the OFN structure. Well
> that's not so bad, except that MFC doesn't allow you to set this
> without creating your own CDocManager class and overriding
> DoPromptFileName, which involves copying a significant chunk of code
> from the MFC source just to add 3 lines:
>
> TCHAR szCurDir[MAX_PATH];
> GetCurrentDirectory(MAX_PATH, szCurDir);
> dlgFile.m_ofn.lpstrInitialDir = szCurDir;
>
> Which restores everything back to something resembling normality!
>
> Now I could understand it (just) if the rule was changed such that the
> dialogs would use the last directory chosen in a common open/save
> dialog with the same filter, but not just ANY open/save dialog in your
> application.
>
> Now if someone knows a way to turn off this behaviour (ideally for a
> single application, but for all is probably better than nothing), I'd
> be most interested. I did read about a NoFileMRU registry setting,
> but I'm not sure exactly where it goes and how it works.
>
> I also figured that you could explicitly search the values under
>
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisited
MRU
>
> for one that matches your application and delete it, but that's hardly
> a pretty solution, or one that's likely to work in future versions of
> Windows.
>
> Anyway, interested if anyone else has had the same frustrations.
>
> Dylan

"Sten Westerback" <sten.westerback@NO_SPAMnokia.com> wrote in message news:<6a2%b.10325$(E-Mail Removed)>...
> You could try with OPENFILENAME_SIZE_VERSION_400
> as lStructSize.
>
And how are you going to get that flag to MFC exactly?
Out of curiosity though, does it work, and what other side-effects does it have?

Dylan

"Dylan Nicholson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Sten Westerback" <sten.westerback@NO_SPAMnokia.com> wrote in message
news:<6a2%b.10325$(E-Mail Removed)>...
> > You could try with OPENFILENAME_SIZE_VERSION_400
> > as lStructSize.
> >
> And how are you going to get that flag to MFC exactly?
Don't use MFC if it doesn't do what you need...

> Out of curiosity though, does it work, and what other side-effects does it
have?
Note tested but it should.

- Sten