Board index » delphi » BP7/DOS in Win95 DOS Box - IOResult problems

BP7/DOS in Win95 DOS Box - IOResult problems

Consider the following test program:

        var F : Text;
        begin
                Assign(F,'BADFILE.TXT');
        {$I-}
                Reset(F);
        {$I+}
                writeln(IOResult);
        end.

If compiled and run from within BP in a Win95 DOS box, the IOResult
value written to screen is zero (despite the fact that BADFILE.TXT does
not exist). If the compiled program is run from the DOS box rather than
from the BP IDE it works fine. (Indeed, if it is run from a DOS shell
from BP7 it still works fine.)

Am I doing something wrong? If not, where's the problem, and can I fix
it?

(I have Win95 OSR 2, btw.)

--
Mark Rogers (Software Engineer)       -o-      m...@controlware.demon.co.uk
2M_ControlWare, Yaxley, Peterborough, ENGLAND.

 

Re:BP7/DOS in Win95 DOS Box - IOResult problems


Quote
Mark Rogers wrote:

> Consider the following test program:

>         var F : Text;
>         begin
>                 Assign(F,'BADFILE.TXT');
>         {$I-}
>                 Reset(F);
>         {$I+}
>                 writeln(IOResult);
>         end.

A better way of doing this is have a VAR error:Integer and then after
your {$I+} put "error:=ioresult;" and "writeln(error);" I don't know if
this will work but it's a more efficient and reliable way of doing it.

--
God's final message to His creation: "We apologize for the
inconvenience"
Devlin Wright, URL: http://www.geocities.com/SiliconValley/Lakes/7568/
I will be OFF-LINE for 3 months from July 4th!!!

Re:BP7/DOS in Win95 DOS Box - IOResult problems


In article <339D20BD.5...@geocities.com>, Devlin of Borg
<locutu...@geocities.com> writes

Quote
>A better way of doing this is have a VAR error:Integer and then after
>your {$I+} put "error:=ioresult;" and "writeln(error);" I don't know if
>this will work but it's a more efficient and reliable way of doing it.

This doesn't make any difference (in fact it's closer to the way I was
actually using Reset in my real code - the posted snippet was just a
simple one to illustrate the problem).

I'm curious to know why you think it's a more efficient and reliable
method, though. Often there are reasons why you have to do this - I've
seen code in the past such as:
        if IOResult = 0 then exit;
        if IOResult = 1 then ....
... which doesn't work because the first call to IOResult clears the
error if there was one. (The above is pretty bad coding - a case
statement would have been simpler, for example - but again it's cut down
to make the point.) This is probably a good reason to use a variable
instead as a general rule. Was this what you were thinking of, or is
there something else?

--
Mark Rogers (Software Engineer)       -o-      m...@controlware.demon.co.uk
2M_ControlWare, Yaxley, Peterborough, ENGLAND.

Re:BP7/DOS in Win95 DOS Box - IOResult problems


In article <33aa3a73.149695...@news.southeast.net>, "R.E.Donais"
<rdon...@southeast.net> writes

Quote

>The problem you describe was discussed a while back.  

Thanks for this. I've actually been subscribed to c.l.p.b since it was
formed, but just haven't had chance to read it recently (along with most
other newsgroups). I do, however, have a large hard disk with high
expiry times, so the chances are if I look hard enough I'll find it
somewhere. (That's at home, and I'm at work right now, which is why I
didn't check back that far before posting.)

--
Mark Rogers (Software Engineer)       -o-      m...@controlware.demon.co.uk
2M_ControlWare, Yaxley, Peterborough, ENGLAND.

Re:BP7/DOS in Win95 DOS Box - IOResult problems


In article <skwjUAAqqnnzI...@controlware.demon.co.uk>, mark-
n...@controlware.demon.co.uk says...

Quote
> In article <33aa3a73.149695...@news.southeast.net>, "R.E.Donais"
> <rdon...@southeast.net> writes

> >The problem you describe was discussed a while back.  

> Thanks for this. I've actually been subscribed to c.l.p.b since it was
> formed, but just haven't had chance to read it recently (along with most
> other newsgroups). I do, however, have a large hard disk with high
> expiry times, so the chances are if I look hard enough I'll find it
> somewhere. (That's at home, and I'm at work right now, which is why I
> didn't check back that far before posting.)

Hopefully this will save you some time. I ran in to the same problem a
while back myself.

Solution 1:

Quote
> The following code worked for me for YEARS, but now fails when I run
> the program with the internal de{*word*81} on (Pentium Pro 200):

> assign(fn,'non_existent_file');
> {$i-}reset(fn);{$i+}
> if ioresult = 0 then begin
>         do stuff when file exists....
> end;

> the program ALWAYS tell me the file exists, and opens it for input
> from the keyboard if it does not exist. This is indeed a shocker!

On december 11th, I wrote that the reset/ioresult test would issue a
false report for a file that is on the DOS path but not in the current
directory. As someone else rightly corrected, this is true for APPEND
but not for PATH. The Append statement is rarely used nowadays, but I
have it in my autoexec.bat file so an old application I use can find
its overlays. The directory I 'appended' is also in my Dos path, which
led me to the wrong conclusion.

Still the reset/ioresult test seems to give false reports in some
environments. I still think it is quite possible that the FindFirst
method will always give the right result, also in those environments
where reset/ioresult fails. I would really appreciate if this could be
verified by those that can reproduce the puzzling situation that
Herbert Gintis reported.

So I repeat the test program I posted on december 11th, with the two
functions  exist1 and exist2. I think it's ready to compile on all
Borland Turbo Pascal compilers used nowadays. Try it. Enter existing
and non-existing filenames with/without a path, wildcards, you name
it. Stop the program by pressing Enter without a filename. This last
'empty filename' test always gives me the result 'exist1=true,
exist2=false', meaning that function exist1 falsely reports that there
is a file without a name on my disk, while exist2 rightly reports
there is no such file. When run from a DOS IDE, you will have to look
back at the 'user screen' to verify this ('Debug|User screen' (BP7)
or 'Run|User screen' (TP55) or Alt+F5).

Is there anyone that knows of a situation where function exist2 fails?

Bob Ferguson.

-------------------------------

PROGRAM EXIST;

{$IFDEF WINDOWS}
uses WinDos, WinCRT, Strings;
{$ELSE}
uses Dos;
{$ENDIF}

var fname: String;

function exist1(fname: string): boolean;
var fvar: file;
begin
  assign(fvar,fname);
  {$I-} reset(fvar); {$I+}
  if IOResult = 0 then begin close(fvar); exist1:= true end
  else exist1:= false;
end;

{$IFDEF WINDOWS}
function exist2(fname: string): boolean;
const fatr= faAnyFile and not (faDirectory or faVolumeID);
var srec: TSearchRec; fnmZ: Array[0..255] of Char;
begin
  if (Pos('*',fname)>0) or (Pos('?',fname)>0) then exist2:= false
  else begin
    FindFirst(StrPCopy(fnmZ,fname),fatr,srec);
    exist2:= DosError = 0;
  end;
end;
{$ELSE}
function exist2(fname: string): boolean;
const fatr= AnyFile and not (Directory or VolumeID);
var srec: SearchRec;
begin
  if (Pos('*',fname)>0) or (Pos('?',fname)>0) then exist2:= false
  else begin
    FindFirst(fname,fatr,srec);
    exist2:= DosError = 0;
  end;
end;
{$ENDIF}

begin {program EXIST}
  repeat
    write('Enter filename: ');
    readln(fname);
    writeln('exist1 : ',exist1(fname));
    writeln('exist2 : ',exist2(fname));
    writeln;
  until fname='';
end.

Solution 2:

function exist( Name : string ) : boolean;

VAR
   F : file;
   SR : SearchRec;

begin
   FindFirst( Name, Anyfile, SR );
   Exist := DosError=0;
end;

Re:BP7/DOS in Win95 DOS Box - IOResult problems


My apologies if I am off topic, I haven't been lurking here for a
while.  Is this the IoResult shows success even when the file isn't
there problem?  If it is, do you have Norton on your system?  Let me
know if I'm on target and if you need more details.  If I've missed
the point, please excuse the post.

On Wed, 11 Jun 1997 07:25:00 -0700, cebs...@jpb.pbz (Professor Zen)
wrote:

Quote
>In article <skwjUAAqqnnzI...@controlware.demon.co.uk>, mark-
>n...@controlware.demon.co.uk says...
>> In article <33aa3a73.149695...@news.southeast.net>, "R.E.Donais"
>> <rdon...@southeast.net> writes

>> >The problem you describe was discussed a while back.  

Dennis D. Powers
PC/POLL SYSTEMS
Den...@pcpoll.com

Support the anti-Spam amendment
Join at http://www.cauce.org/

Re:BP7/DOS in Win95 DOS Box - IOResult problems


In article <HsMpWDAfB$mzI...@controlware.demon.co.uk> of Mon, 9 Jun 1997
13:00:31 in comp.lang.pascal.borland, Mark Rogers <mark-

Quote
n...@controlware.demon.co.uk> wrote:

>Consider the following test program:

>        var F : Text;
>        begin
>                Assign(F,'BADFILE.TXT');
>        {$I-}
>                Reset(F);
>        {$I+}
>                writeln(IOResult);
>        end.
> ...

There's a bit of file testing in
        http://www.merlyn.demon.co.uk/programs/chk_xist.pas
GetFAttr seems useful; but I cannot test it in your environment.

--
John Stockton, Surrey, UK.    j...@merlyn.demon.co.uk    Turnpike v1.12    MIME.
  Web URL: http://www.merlyn.demon.co.uk/ -- includes FAQqish topics and links.
  Correct 4-line sig separator is as above, a line comprising "-- " (SoRFC1036)
  Before a reply, quote with ">" / "> ", known to good news readers (SoRFC1036)

Re:BP7/DOS in Win95 DOS Box - IOResult problems


In article <MPG.e085519a71af6b4989...@news.wco.com>, Professor Zen
<cebs...@jpb.pbz> writes

Quote

>Hopefully this will save you some time. I ran in to the same problem a
>while back myself.

Thanks for this - yes it did save me the search.

It looks like either FindFirst or GetFAttr (see John's post) will do the
trick.

Does anyone know where the problem lies? Ie Win95, BP7's IDE, Reset RTL
code, etc? It's going to be a pain to work around this one, especially
given that it's only necessary when running from the IDE.

--
Mark Rogers (Software Engineer)       -o-      m...@controlware.demon.co.uk
2M_ControlWare, Yaxley, Peterborough, ENGLAND.

Re:BP7/DOS in Win95 DOS Box - IOResult problems


In article <PJWLbHAXeunzE...@merlyn.demon.co.uk>, Dr John Stockton
<j...@merlyn.demon.co.uk> writes

Quote

>There's a bit of file testing in
>        http://www.merlyn.demon.co.uk/programs/chk_xist.pas
>GetFAttr seems useful; but I cannot test it in your environment.

As it happens, I downloaded this only yesterday. I have just checked it,
and yes it does appear to work in my environment - thanks.

--
Mark Rogers (Software Engineer)       -o-      m...@controlware.demon.co.uk
2M_ControlWare, Yaxley, Peterborough, ENGLAND.

Re:BP7/DOS in Win95 DOS Box - IOResult problems


On Thu, 12 Jun 1997 12:29:25 +0100, Mark Rogers

Quote
<mark-n...@controlware.demon.co.uk> wrote:

>Does anyone know where the problem lies? Ie Win95, BP7's IDE, Reset RTL
>code, etc? It's going to be a pain to work around this one, especially
>given that it's only necessary when running from the IDE.

>--
>Mark Rogers (Software Engineer)       -o-      m...@controlware.demon.co.uk
>2M_ControlWare, Yaxley, Peterborough, ENGLAND.

I missed the beginning of this thread.  Are you talking about the
IoResult being Zero when the file is not there?  If so, are you
running Norton?

Dennis D. Powers
PC/POLL SYSTEMS
Den...@pcpoll.com

Support the anti-Spam amendment
Join at http://www.cauce.org/

Other Threads