Re: Opening a file - File Open Dialog spoils future code
Pete Lomax wrote:
>
> 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.
Yes, I probably should have read your post more carefully.
> 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?
I agree that it's a good thing. I was trying to figure out what affected
CChris such that the behavior of current_dir didn't make sense. So far,
the open dialog is the only other thing that I'm aware of that would
affect this, and that's from the application's process, so we clearly
haven't figured it out yet.
> [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 think it's up to the library author to identify where such changes occur
and to either restore the state, or to document that such things occur.
Restoring the state could be problematic. What if you have an open dialog
up, and some other event is triggered, and the app changes the current
directory? It seems to me that this could cause other problems with the
dialog, anyway, but even if it doesn't, the library could be restoring
stale data, which would be a problem.
> 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.
Well, you should just debug before you distribute your program. :P
And having the ex.err file appear in some random place probably isn't
helpful either. I suppose that you could always create a place in the
user's home directory to put the error message. You also shouldn't
be polluting places like the Program Files folder, since you'll require
admin access. Likewise, writing to /usr/bin is to be frowned upon.
> 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.
Well, it's possible that the Watcom runtime library might not use the
OS' idea of current directory, and just maintain its own. Fortunately,
that's not the case.
Matt
|
Not Categorized, Please Help
|
|
