Re: Opening a file - File Open Dialog spoils future code
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
|
Not Categorized, Please Help
|
|
