OpenEuphoria

Re: Opening a file - File Open Dialog spoils future code

• Posted by Pete Lomax <petelomax at blueyond?r.c?.uk> Jan 17, 2008
• 529 views

Matt Lewis wrote:
> 
> OK, I found an easy way to unwittingly change the current directory.
> }}}
<eucode>
> void = getOpenFileName( 0, "", {})
> </eucode>
{{{


Ah, if you only just realised that then my post of 19:27 may not have meant very
much to you.

This behaviour is actually quite desireable - suppose you getOpenFileName and
say it starts in C:\My Documents And Settings, so you navigate to and open
D:\mystuff\projectX\subthings\wotsit.txt. Now imagine you want to open another
nine files in the same directory. How annoying would it be if the  next nine
open/save pop-ups all started in C:\My Documents And Settings?

[Moot point, perhaps, not as if we can change comdlg32.dll anyway.]

Obviously it is the impact on open() at question here.

While explicit chdir() should affect open(), the more I think on, it *is* the
job of win32lib (and arwen etc) to mask this somewhat more hidden effect from
getOpen/SaveFileName. I suppose a bit like having two "current dir"; one for the
application proper, and one for the gui wrapper around it.

I would agree with a proposal to cause the interpreter to create ex.err in that
same place it initially finds main.exw/main.exe, no matter what chdir() etc
happen before the error. However I understand there is a problem with this, (not
that I much care,) eg running from CDROM.

BTW, I am looking on with some amusement at the whole clib vs winAPI thing, like
one's gonna make your disk spin in the opposite direction or something.
Dunno where it sprang from, but quite obvious to me utterly irrelevant.

Regards,
Pete