Re: capi:prompt-for-file vs. current-working-directory

Paul Tarvydas <tarvydas <at> visualframeworksinc.com> writes:
> 
> On LWW 5.1, it seems that when I call capi:prompt-for-file, the current 
> working directory gets changed after successful return.  This is causing me 
> grief.
> 
> Is this a bug, or my own misunderstanding of the documentation / intended 
> operation?

Paul,

At my last job we had a similar problem to this for *months* (albeit in VC++ 
using MFC). Note: this was several years ago, so some of this is hazy...

If you check out the documentation for GetOpenFileName (the underlying Win32 
function, which LWW probably uses), somewhere - and sorry, but I don't remember 
where - we discovered that selecting the file actually alters the current 
working directory. This caused us no end of headaches until it was discovered.

There's actually an [undocumented] flag that one can pass to the function so as 
to not change the current working directory, but alas, it's also unsupported 
and only worked for a brief period of time (if it ever worked at all). IIRC, 
whether or not the directory changed was due to a user setting in the registry. 
Something akin to "open file dialogs automatically re-open to the directory of 
the last file I opened."

Anyway, I don't believe this to be a LWW problem, but rather a "feature" of 
Windows. On our particular project, we ended up writing our own open file 
dialog and later discovering a better one someone else had written to overcome 
the same problem. You may be able to just get away with saving the current 
working directory, opening the file, then restoring it right away. How I wish 
we could have done that... stupid multi-threading. ;-)

HTH,

Jeff M.