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.
>
> 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?
1/ An application may process files in different sibling subdirectories of a
same directory. Having to always hop to parent and then to sibling is not
desirable.
2/ The issue is that there are two ways of opening a file: with prior visual
selection by GetOpenFileName() and without it. The former apparently affects the
latter, and that is one of the problems. Note that opening a file with visual
selection never errs, because the fully qualified path is retrieved.
>
> [Moot point, perhaps, not as if we can change comdlg32.dll anyway.]
>
Of course (well, hotfixes d work). But we can override some of its misfeatures.
I'm not sure the unexpcted changes stem only from selecting a file.
> 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.
>
Could you detail the logic that backs your assertion?
A GUI wrapper is just yet another include file - there might be one for Internet
interaction, one for SCSI device management and whatnot -. arwen.ew has no idea
it is being icluded my joe\myApp.exw, so it can't help with the open() statements
the latter issues. And console application won't use these wrappers anyway. So it
doesn't make any sense to ask the GUI wrapper to manage calls to open() with an
unqualified file name as first argument.
What you launch is <full path of exw[c].exe> <full path of myApp.exw> <extra
optional stuff>, with a varying degree of implicitness. Hence, managing open() is
to be done in either exw.exe or myApp.exw, and nowhere else. And since the
interpreter already handles some open() calls on behalf of myApp.exw - an include
statement results in one or more such calls -, it would certainly be consistent
that the interpreter handles them all. myApp.exw is obviously free to override
the interpreter by making its own API calls, wrapped or not.
> 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.
In that case, it falls back on whatever directory EUDIR is set to. If EUDIR is
not set, or open() fails on the destination, it just bails out, possibly with an
explanatory dialog box. Simple and effective.
Now what about myApp.exw issuing }}}
<eucode>open("myFile.txt","r")</eucode>
{{{
? The
least surprise principle would suggest the implied directory is the one myApp.exw
is in and that's the interpreter's job to enforce that, using the same rule for
both ex.err and myFile.txt.
In a nutshell: open() should ignore the erratic Windows current directory and
stick to the only thing user knows about, to wit, where myApp.exw and exw.exe
are. And it doesn't need to mess with it, because starting the open dialog where
it had left makes sense, even if it is not always desirable - but the API allows
to set the initial directory anyway; I recently posted the rules which apply when
no such init is performed -.
CChris
>
> 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
|
Not Categorized, Please Help
|
|
