Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Fehler 100 bei Turbo 7 unter NT 4.0

2 views
Skip to first unread message

ZG

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to

ZG <zg.ra...@t-online.de> schrieb in im Newsbeitrag: ...
> Hallo,
>
> ich habe wahrscheinlich ein ganz einfach zu lösendes Problem, welches ich
> aber im Moment nicht lösen kann.
>
> (Turbo7 läuft bei mir unter WinNT 4.0)
> Es handelt sich um das Problem - EINLESEN EINER TEXTDATEI bzw. Einlesen
der
> Dateiinhalte. Dies ist eine stinknormale Textdatei mit Datensätzen (siehe
> nachstehend abgespeckte Beispieldatei mit vier Datensätzen). Compiler
bringt
> keine Fehlermeldung. Programm wird auch richtig ausgeführt bis zur
> FEHLERMELDUNG - Fehler 100: Lesefehler von Diskette/Platte - READ-Befehl
> löst diesen Fehler aus, wenn versucht wird über das Ende einer typisierten
> Datei hinaus weitere Daten zu lesen!
>
> 004002100309970844001702088910 3.000 13.8900N 3.000
> 004002200309970324001702088606 5.000 9.3900N 5.000
> 004002300309970504001702020637 2.000 19.9800N 2.000
> 004002400309970484001702089320 4.000 13.4700N 4.000
>
>
> Diese Datei habe ich versucht mit dem READ-Befehl versucht einzulesen:
>
> TYPE Datentyp = Record of
> Daten_Feld : STRING;
> End;
>
> VAR TEST : Datentyp;
>
>
> Assign(OUT_TXT_Datei, 'c:\out.txt' );
>
> Reset(OUT_TXT_Datei);
>
> While not EOF(OUT_TXT_Datei) do
> Begin
> With TEST do
> Begin
> Read(OUT_TXT_Datei, TEST);
> End;
> End;
>
> Close(OUT_TXT_Datei);
>
>
> Wie kann ich die Datei zur Bearbeitung (evtl. gleich Aufsplittung der
> Satzart in entsprechende Felder) in mein Pascal-Programm zur Bearbeitung
> einlesen???
> Bzw. gibt es eine andere Möglichkeit wie die oben von mir beschriebene
> Art???
>
> Bitte sendet Eure Rückmeldung an folgende Adresse:
>
> zg.955.m...@t-online.de
>
> Danke
> Timo
>
>
>
>
>
>
>
>
>

Konstantin Koll

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to
(A problem occurs when reading behind the end of a binary file unter NT
4.0)

Thanks for the hint. I've experienced the same with Blockrad under
Windows NT. Seems to be a bug under NT or something...

Horst Kraemer

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to

No. It's a bug in your program.

Reading beyond end of file gives a TP RTE 100 (if you are not using
{$I-}) on any operating system - with 2 exceptions:

1) You are using the file type TEXT. In this case string variables
return the empty string, char variables return $1A (^Z) and numeric
variables return 0. One of the reasons for this is that the character
$1A is treated as an artificial EOF marker and you can read it away
(in spite of EOF) by read(f,charvar).


2) You are using the type FILE (untyped) _and_ you are providing the
fourth parameter of type word to blockread which indicates the number
of blocks actually read.

A simple

blockread(f,buff,count);

will crash after eof. But

blockread(f,buff,count,result);

will not crash after eof because you took the responsability to check
after reading if count=result.


Regards
Horst


Konstantin Koll

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to
Sorry, I really use the following throughout the program:

BlockRead(File,Buffer,MaxiumSize,Dummy);

where Dummy is a Word variable. Under DOS and Win9x, it's ok, but under
NT, is causes Runtime error #216 (GPF). Strange...

Horst Kraemer

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to

OK. GPF is not RTE #100. So it appears that it's not Borland's fault.

Is it a RM program or a DPMI program ?

Are you sure that the GPF only occurs _after_ eof(f) is true ?

Are you sure that you did reset the file using 'reset(f,1)' ?

Are you sure that the buffer is big enough ?


Regards
Horst


Konstantin Koll

unread,
Apr 21, 1999, 3:00:00 AM4/21/99
to
The fault ONLY occurs with a DPMI program.
Runtime error #216 occurs when closing the file.
Of course I reset the file, since I'm using a function that assigns and
resets a file. The buffer is also big enough.

0 new messages