OpenEuphoria

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

• Posted by CChris <christian.cuvier at agriculture?go?v.fr> Jan 16, 2008
• 542 views

Mike777 wrote:
> 
> So far, it seems like everybody (other than me, of course) has been spot on
> when debugging my problems, even when there isn't enough information to make
> a definitive determination.
> 
> For that, I'm very thankful.
> 
> But I've got one here that has me really scratching my head in puzzlement as
> to the basic issue.  I am trying to open a file for reading.  Most of the
> time,
> the file will open just fine and I can read in the sequence that is stored
> therein.
>  But in one circumstance (at least I have identified only one circumstance so
> far) the file doesn't open.  It just returns a -1.  So I created a copy of the
> file with a slightly different name and when a -1 comes back I try to open the
> other file.  No go.  So it has nothing to do with the file being already open
> or in use by another app, because the other file name isn't referenced
> anywhere
> by anything.
> 
> I'm hoping that somebody, right about now, is chuckling to themselves and
> about
> to write me a short description of what is going on and how to fix it.
> 
> In any event, the code to open the file is in a general routine in my
> OptionsWindow
> window under the procedure load_config() (this is called in the onOpen event
> of my OptionsWIndow window - in fact that is the only code in the onOpen
> event):
> 
> procedure load_config()
> integer myInteger,myInteger2, myInteger3
> myInteger = open("MyFileName.CFG","r")
> myInteger3 = 0
> if myInteger > 0 then
> -- ok
>  myInteger3 = 1
> else
>   myInteger = open("MyFileName1.CFG","r")
>   if myInteger > 0  then
>   	myInteger3 = 2
>   end if
> end if
> if myInteger3 = 0 then
>  w32VOID= message_box("Neither file will open.","",0)
> else
>     seqConfig = get(myInteger)
>     seqConfig = seqConfig[2]
>     close(myInteger)
> end if
> 
> if myInteger3 != 0 then
> --- go ahead and put the information into the controls
> end if
> end procedure
> 
> As mentioned above, sometimes this works. Sometimes it doesn't.  When it
> works,
> it does so on the first file (that is, the first file doesn't fail while the
> second file succeeds) and it works just fine.  I don't know whether I can open
> the second file if I am able to open the first file - I've never tried.
> 
> I have isolated the following circumstance which will guarantee that opening
> the file will fail.  To me, there doesn't seem to be any connection, but maybe
> somebody else can spot it.
> 
> On my main window (Window1), I have a menu (FILE), with an option (OPEN)
> which,
> when selected, calls the routine to select a file name.  Once it is selected,
> I actually open that file, read some information from it, and close it (I am
> sure I close it).  From that point on, if I select the OPTIONS|CONFIGURE
> option
> from the main window, the above code fires and fails.
> 
> Here is the code from the FILE|OPEN option:
> 
> procedure mnu_File_Open_onClick (integer self, integer event, sequence params)
> 	integer myInteger, fn
> 	sequence fName,mySeq
> 
> fName = getOpenFileName(
>                           Window1,                  -- parent window
>                           "",                         -- no default name
>                           { "All Files", "*.*" } )    -- everything else
> if length(fName) > 0 then
>     setText(SB,"File: " & fName) -- the file name shows up on the status bar
> just fine
>     setEnable(mnu_File_Save,w32True)
>     setEnable(mnu_File_Close,w32True)
>     fn = open(fName,"r") -- this works
>     mySeq = get(fn)
> 
>     setText(txtFirstControl,mySeq[2][2])
>     setText(txtSecondControl,mySeq[2][4])
>     close(fn)  -- this is where I close the file even though I leave the name
> on the status bar as the "opened" file
> else
>     setText(SB,"File: NONE")
>     setEnable(mnu_File_Save,w32False)
>     setEnable(mnu_File_Close,w32False)
> end if
> 
> end procedure
> 
> I can fire the program and go straight to OPTIONS|CONFIG and the program can
> read the file.  If I first go to FILE|OPEN and select an existing file, then
> when I go to OPTIONS|CONFIG the opening of the file fails.  BTW,
> OPTIONS|CONFIG
> succeeds if I click "Cancel" in the File Open dialog of FILE|OPEN.  This
> points
> to using the Windows File Open dialog.  Yup, if I hardcode the file to be
> opened,
> then I can go straight from FILE|OPEN to OPTIONS|CONFIG and it will work.  So
> I must have bad code where I invoke the Windows File Open dialog.  Can
> somebody
> spot what it is?
> 
> I'm using win32lib, Enhanced IDE and eu v 3.1.1.
> 
> 
> Thanks
> 
> Mike

open() doesn't understand Windows folders, because Windows doesn't have a notion
of a current directory. open() uses the PATH environment variable, which is a
DOS/Unix thing Windows supports for backward compatibility only) and looks for
MyFileName.CFG in places completely different from where Windows looks for them,
so it probably just can't see the file there.
I'd suggest making fName local rather than private. open() won't err given the
absolute path it will contain on return.

As to how the GetOpenFilename() API, hene getOpenFileName(), selects an initial
folder, hee is what MSDN says (formatting got lost in the way):
<quote>
The algorithm for selecting the initial directory varies on different platforms.
Windows 2000/XP:

If lpstrFile contains a path, that path is the initial directory.
Otherwise, lpstrInitialDir specifies the initial directory.
Otherwise, if the application has used an Open or Save As dialog box in the
past, the path most recently used is selected as the initial directory. However,
if an application is not run for a long time, its saved selected path is
discarded.
If lpstrInitialDir is NULL and the current directory contains any files of the
specified filter types, the initial directory is the current directory.
Otherwise, the initial directory is the personal files directory of the current
user.
Otherwise, the initial directory is the Desktop folder.
Windows 98/Me:

lpstrInitialDir specifies the initial directory.
If lpstrInitialDir is NULL and lpstrFile contains a path, that path is the
initial directory.
Otherwise, if the current directory contains any files of the specified filter
types, the initial directory is the current directory.
Otherwise, the initial directory is the personal files directory of the current
user.
Earlier versions of Windows and Windows NT:

lpstrInitialDir specifies the initial directory.
If lpstrInitialDir is NULL and lpstrFile contains a path, that path is the
initial directory.
Otherwise, the initial directory is the current directory.
</quote>

The way getOpenFileName() works, lpstrInitialDir is NULL on calling the API.
Currently, the only way to set it is to build an OPENFILENAME yourself using
w32to_memory(), calling w32Func(xGetOpenFileName,{your_struct}) and retieving the
selected file from the structure. That cursed Euphoria simplicity again... And
I'd have to create another routine name (say getOpenFileNameEx()) in order to
stick in any extra information.

HTH
CChris

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

• Posted by CChris <christian.cuvier at agri?ulture.g?uv.fr> Jan 16, 2008
• 522 views

Matt Lewis wrote:
> 
> CChris wrote:
> > 
> > open() doesn't understand Windows folders, because Windows doesn't have a
> > notion
> > of a current directory. open() uses the PATH environment variable, which is
> > a DOS/Unix thing Windows supports for backward compatibility only) and looks
> > for MyFileName.CFG in places completely different from where Windows looks
> > for
> > them, so it probably just can't see the file there.
> 
> I thought that it did, and that %PATH is only used for executables and for
> dlls.  What do current_dir() and chdir() do then?
> 
> Matt

They do return something which is defined in the C library used to compile the
source, so the answer lies in a black box. Does anyone know what they do under
Windows? At any rate, I have learnt not to use open() with unqualified file
names.
As far as I remember from the discussion about where to put euinc.conf, it was
decided not to rely on the current directory precisely for that reason.

CChris

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

• Posted by Andy Drummond <andy at kest?el?ele.com> Jan 16, 2008
• 517 views

CChris wrote:
> 
> Matt Lewis wrote:
> > 
> > CChris wrote:
> > > 
> > > open() doesn't understand Windows folders, because Windows doesn't have a
> > > notion
> > > of a current directory. open() uses the PATH environment variable, which
> > > is
> > > a DOS/Unix thing Windows supports for backward compatibility only) and
> > > looks
> > > for MyFileName.CFG in places completely different from where Windows looks
> > > for
> > > them, so it probably just can't see the file there.
> > 
> > I thought that it did, and that %PATH is only used for executables and for
> > dlls.  What do current_dir() and chdir() do then?
> > 
> > Matt
> 
> All right, I should have checked first, but the bottom line is the same: never
> use current_dir() under Windows. Here is what I found on MSDN:
> <quote>
> The directory at the end of the active path is called the current directory;
> it is the directory in which the active application started, unless explicitly
> changed. An application can determine which directory is current by calling
> the GetCurrentDirectory function.
> 
> An application can change the current directory by calling the
> SetCurrentDirectory
> function.
> </quote>
> 
> I have recently wondered why I wasn't finding ex.err after a program crash.
> Searching ex.err on my machine reported 9 different directories, some of which
> I'd havd never thought about. Since ex.err is created using
> open("ex.err","w"),
> I consider the "current directory" to be undefined for practical use: it is
> defined, but as something volatile (what is the active application on a
> multiprocess
> platform?). I'd go as far as recommending to drop support of current_dir() and
> chdir() under Windows.
> 
> CChris

I disagree CChris.  There IS such a thing as the current directory; just because
a program can change it doesn't make it less valid.  Ex.err gets dumped into
the current directory, which is why it is a good idea to use crash_file() to
be sure your ex.err gets put where you want.  The current directory is where
the file system performs actions unless otherwise instructed. If I say something
like open("fred.fil","r") Windows will attempt to open that file in the current
directory - where ever that may be.  Current directory is simply a default
folder
to access in the absence of further information. I get and set current directory
all the time; if you took them out I'd put them into my own library!!

AndyD

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

• Posted by Pete Lomax <petelomax at blueyonder??o.uk> Jan 16, 2008
• 519 views
• Last edited Jan 17, 2008

Mike777 wrote:
> 
> Thanks to all.  I *knew* it was something simple that I just wasn't seeing.
>  Fully specifying the path for the file was an easy fix.
> 
A bit late now then, but for future reference I was about to suggest this:

sequence saveDir
saveDir=current_dir()
fName = getOpenFileName(...)
if not chdir(saveDir) then ?9/0 end if

I guess (random thought of the day) that if win32lib wanted to do this it ought
to have a flag and a saved dir of it's own, maybe:

integer goDirValid  goDirValid=0
sequence goDir

function getOpenFileName(..,fName,..)
sequence sDir
  sDir=current_dir() -- so that open("xxx.config") is unaffected by this
  if goDirValid      -- so that next getOpenFileName starts where expected
  and length(fName)=0 then -- goDir would have no effect in this case
      if not chdir(goDir) then ?9/0 end if
  end if
  ...
  goDir=current_dir()
  goDirValid=1
  if not chdir(sDir) then ?9/0 end if
  return result
end function

Then again, this might cause all kinds of subtle incompatibility problems...

Regards,
Pete

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

• Posted by CChris <christian.cuvier at agr?cult?re.gouv.fr> Jan 16, 2008
• 518 views
• Last edited Jan 17, 2008

Matt Lewis wrote:
> 
> CChris wrote:
> > 
> > All right, I should have checked first, but the bottom line is the same:
> > never use current_dir() under Windows. Here is what I found on MSDN:
> > <quote>
> > The directory at the end of the active path is called the current
> > directory; it is the directory in which the active application started,
> > unless explicitly changed. An application can determine which directory
> > is current by calling the GetCurrentDirectory function.
> > 
> > An application can change the current directory by calling the
> > SetCurrentDirectory function.
> > </quote>
> 
> I don't see how your conclusion follows from this.  Perhaps we could/should
> alter the behavior of the interpreter under windows to call the win32
> functions instead of the c library.
> 
> > I have recently wondered why I wasn't finding ex.err after a program crash.
> > Searching ex.err on my machine reported 9 different directories, some of
> > which I'd havd never thought about. Since ex.err is created using
> > open("ex.err","w"), I consider the "current directory" to be undefined for
> > practical use: it is defined, but as something volatile (what is the active
> > application on a multiprocess platform?). I'd go as far as recommending to
> > drop support of current_dir() and chdir() under Windows.
> 
> I think you've misunderstood what MSDN was saying.  You can change the current
> dir for your app, not for the system.  It's only volatile in that you can
> change it.  It shouldn't change based on other processes.
> 
> I have been annoyed at times by where ex.err is created.  Perhaps that's
> another enhancement to be considered.  But I don't think that it means that
> we should abandon current_dir/chdir.
> 
> Matt

I am only saying two things:
1/ since ex.err may land in folders from where no Eu rogram was ever run, other
processes must interfere in some cases (in case of a crash? I don't know);
2/ since use of the current directory is so confusing for practical use under
Windows, and since there is such an excessive concern about avoiding confuion in
the language, I think relying on what the "current directory" happens to be in an
only mildly deterministic way (from the user standpoint) should be actively
discouraged in some way.

To reply to Pete's post: I don't think this would be win32lib's job. The
interpreter should lock the "current directory" for exw[c].exe to be the one
where the file which is being run lies, and nullify any change not deliberately
made by the .exw being run. Otherwise, users should be specifically advised about
the seemingly random changes it may undergo and their consequences.

CChris

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

• Posted by Jason Gade <jaygade at yahoo.c?m> Jan 16, 2008
• 527 views
• Last edited Jan 17, 2008

Greg Haberek wrote:
> If anything, chdir() and current_dir() should use the Win32 API routines
> instead
> of the c library routines. I'm all for this. :)
> 
> -Greg

Couldn't that effect Windows command line programs or introduce subtle bugs
between command line programs on different platforms?

I would just leave chdir() and current_dir() as is and implement the Win32
specific directory routines in the lib, and recommend that users use those
routines.

Make a note in the documentation that Windows routines have side effects on
chdir() and current_dir().

--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

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

• Posted by Matt Lewis <matthewwalkerlewis at ?mail.c?m> Jan 16, 2008
• 530 views
• Last edited Jan 17, 2008

CChris wrote:
> 
> I am only saying two things:
> 1/ since ex.err may land in folders from where no Eu rogram was ever run,
> other
> processes must interfere in some cases (in case of a crash? I don't know);
> 2/ since use of the current directory is so confusing for practical use under
> Windows, and since there is such an excessive concern about avoiding confuion
> in the language, I think relying on what the "current directory" happens to
> be in an only mildly deterministic way (from the user standpoint) should be
> actively discouraged in some way.

I've run a simple test, and the c-library and win32 routines seem 
interchangeable, which isn't surprising, since the runtime library probably
just wraps the win32 functions.  Now we need to find the magic that disrupts
this behavior:

include dll.e
include file.e
include machine.e
object void
constant 
k32 = open_dll("kernel32.dll"),
GetCurrentDirectoryA = define_c_func( k32, "GetCurrentDirectoryA", {C_INT,
C_POINTER}, C_INT ),
SetCurrentDirectoryA = define_c_func( k32, "SetCurrentDirectoryA", {C_POINTER},
C_INT )

function pwd()
	atom buf, chars
	sequence d
	buf = allocate( 1025 )
	chars = c_func( GetCurrentDirectoryA, {1024, buf})
	d = peek( buf & chars )
	free( buf )
	return d
end function

procedure cd( sequence d )
	atom buf, ok
	
	buf = allocate_string( d )
	ok = c_func( SetCurrentDirectoryA, {buf})
	free(buf)
end procedure

procedure checkdir()
	printf(1, "current_dir: '%s'\n", {current_dir()})
	printf(1, "Win32:       '%s'\n\n", {pwd()})
end procedure

puts(1, "The starting current_dir():\n")
checkdir()

puts(1, "Calling chdir(\"..\")\n")
void = chdir("..")

checkdir()

puts(1, "Calling cd(\"..\")\n")
cd( ".." )

checkdir()

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

• Posted by CChris <christian.cuvier at agri?ulture.?ouv.fr> Jan 17, 2008
• 524 views

Matt Lewis wrote:
> 
> CChris wrote:
> > 
> > I am only saying two things:
> > 1/ since ex.err may land in folders from where no Eu rogram was ever run,
> > other processes must interfere in some cases (in case of a crash? I don't
> > know);
> > 2/ since use of the current directory is so confusing for practical use
> > under Windows, and since there is such an excessive concern about avoiding
> > confuion in the language, I think relying on what the "current directory"
> > happens to be in an only mildly deterministic way (from the user standpoint)
> > should be actively discouraged in some way.
> 
> OK, I definitely think we need to investigate this some more, including to
> find a repeatable way to mess up the current dir so that it does not 
> behave in the obvious way.  I'm not convinced yet that there is strange
> behavior, though I wouldn't be terribly surprised if there were some 
> difference based on using the c-library routine vs the Win32 routine.
> That should be fairly easy to test.  There may be other ways to change 
> the current dir, such as opening a file (at least from the c-library's 
> perspective--again, some testing is required).
>  
> > To reply to Pete's post: I don't think this would be win32lib's job. The
> > interpreter should lock the "current directory" for exw[c].exe to be the
> > one where the file which is being run lies, and nullify any change not
> > deliberately made by the .exw being run. Otherwise, users should be
> > specifically advised about the seemingly random changes it may undergo
> > and their consequences.
> 
> I think that if a library does something that may interfere with the user
> (such as calling chdir) then the library should either attempt to restore
> whatever it changed, or at least document when something like that changes,
> so that users will be able to understand that they might need to check
> for it.
> 
> Matt

This is fine as long as the interference an included file causes. But obviously
there are other cases, and the lock would apply only to these. As I said, I found
a couple ex.err files in places that had never seen an Eu program. If one was
ever launched by the Run... menu while this directory was displayed by Explorer,
then the interpreter should correct this setting which hardly relates to the
user's intent - but thats only an hypothesis.

By the way, the C library doesn't open files by sheer magic; chances are that it
uses the Windows API too, but in ways that may not be documented by the compiler,
and might differ across compilers.

CChris

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

• Posted by Matt Lewis <matthewwalkerlewis at gma?l.?om> Jan 17, 2008
• 516 views

don cole wrote:
> 
> CChris,
> 
>    I would likwe to see some example code using the funtions
> SetCurrentDirectory and getCurrentDirectory. TIA

Don,

RTFF.  I posted some code last night.

Matt

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

• Posted by CChris <christian.cuvier at a?riculture.gouv.?r> Jan 17, 2008
• 537 views

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

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

• Posted by c.k.lester <euphoric at ckl?ster.com> Jan 17, 2008
• 528 views
• Last edited Jan 18, 2008

Matt Lewis wrote:
> 
> And having the ex.err file appear in some random place probably isn't
> helpful either.

How about for .euinc.conf there's this:

EULOG=%APP%
or
EULOG=C:\EULOGS\

or somesuch. That could be cool. Apache does this. All its log are located
in one directory. Although, I do prefer the ex.err file to be located in the
same directory as the source file ("%APP%")... but if somebody had another
preference, maybe this could let them determine their own destiny. :)

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

• Posted by c.k.lester <euphoric at cklest?r.com> Jan 17, 2008
• 551 views
• Last edited Jan 18, 2008

Robert Craig wrote:
> 
> Perhaps there is some value in that,
> but I get the feeling that some people in this discussion
> are forgetting that there is already a way
> to specify exactly where you want the ex.err file to go:

There are probably a few things about Euphoria I don't use to full capacity
(to the detriment of my programming life). :)

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

• Posted by don cole <doncole at pac??ll.net> Jan 17, 2008
• 529 views
• Last edited Jan 18, 2008

Matt Lewis wrote:
> 
> don cole wrote:
> > 
> > CChris,
> > 
> >    I would likwe to see some example code using the funtions
> > SetCurrentDirectory and getCurrentDirectory. TIA
> 
> Don,
> 
> RTFF.  I posted some code last night.
> 
> Matt

Sorry Matt,

I didn't see that, maybe it showed up after I read.

Thanks anyways.

Don Cole