Board index » delphi » Couple Questions...

Couple Questions...

Howdy All!

I have a couple questions from things I'm currently working on in TP7.

The first is a situation where I have an untyped file which I am reading
in 8 variables with BLOCKREAD.  I then display the values in the
variables to the screen with WRITELN (so far so good).  I then have the
ability to modify the values however I want, using READKEY to get the
button I press and use a series of IF-THEN statements to run the put up
the apropriate prompt and accept my input (Here's where the problem
occurs).  If the I choose any of the options availible the program locks
up and I have to give the three finger salute.  If the I hit a button
that doesn't do anything according to the program, it just brings the
prompt back up to choose an option.  So it only locks up when there's an
action to go with the button.  Any ideas here?

I'm also curious.  Say you create a record:

        TYPE GROUPEDVAR = RECORD
                x : char;
             end;

What's the proper way to access 'x' and to save it to a file?

CYA,
Christian

 

Re:Couple Questions...


Quote
Christian McArthur wrote:
> Howdy All!

> I have a couple questions from things I'm currently working on in TP7.

> The first is a situation where I have an untyped file which I am reading
> in 8 variables with BLOCKREAD.  I then display the values in the
> variables to the screen with WRITELN (so far so good).  I then have the
> ability to modify the values however I want, using READKEY to get the
> button I press and use a series of IF-THEN statements to run the put up
> the apropriate prompt and accept my input (Here's where the problem
> occurs).  If the I choose any of the options availible the program locks
> up and I have to give the three finger salute.  If the I hit a button
> that doesn't do anything according to the program, it just brings the
> prompt back up to choose an option.  So it only locks up when there's an
> action to go with the button.  Any ideas here?

Perhaps you have a scope problem, either a misplaced ; or a mismatched
begin/end pair.  It's easy to get wrong with a series of if-then or
if-then-else statements, such as an else being matched up with the wrong
if statement.  If your code isn't neat, try reformatting; that might
bring out errors that otherwise wouldn't be obvious.

Quote
> I'm also curious.  Say you create a record:

>         TYPE GROUPEDVAR = RECORD
>                 x : char;
>              end;

> What's the proper way to access 'x' and to save it to a file?

I'd have to assume your record has more fields than just one, otherwise
a record is pointless.  But what you'd need to do is create a variable
of your record type, then use the "." operator to specify a field, such
as:

var
  myrec : GROUPEDVAR;

begin
  myrec.x := 'c';
end;

Saving it to a file is rather an ambiguous question.  It depends greatly
on how you plan to work with the data (untyped files, typed files, and
so forth).  If you want to learn more about I/O, try looking into the
FAQs and tutorials available for TP.  Pointers are posted weekly.

Quote
> CYA,
> Christian

--
Scott Earnest        | We now return you to our regularly |
set...@ix.netcom.com | scheduled chaos and mayhem. . . .  |

Re:Couple Questions...


Howdy all!

I've been working on figuring ot what's wrong with my code and why the
program locks up.  I found the least amount needed for it to lock up,
here it is:

program BTCONFIG;
uses Crt;

var  cfgfle  : file;

     btdir   : string;
     droploc : string;
     dropfile: string;
     tstart  : string;
     tend    : string;
     maxplay : byte;
     numbat  : byte;
     tourny  : char;

begin
  clrscr;
  writeln('***PROGRAM STARTED***');
  assign(cfgfle, 'BTCONFIG.DAT');
  reset(cfgfle);
  writeln('***READING FROM .DAT***');
  blockread(cfgfle, btdir, 1);
  blockread(cfgfle, maxplay, 1);
  blockread(cfgfle, numbat, 1);
  blockread(cfgfle, tourny, 1);
  blockread(cfgfle, tstart, 1);
  blockread(cfgfle, tend, 1);
  blockread(cfgfle, droploc, 1);
  blockread(cfgfle, dropfile, 1);
  writeln('***FINISHED READING***');
  seek(cfgfle, 0);
  writeln('*****MOVED TO BEGINING OF CONFIG FILE*****');
  blockwrite(cfgfle, btdir, 1);
  blockwrite(cfgfle, maxplay, 1);
  blockwrite(cfgfle, numbat, 1);
  blockwrite(cfgfle, tourny, 1);
  blockwrite(cfgfle, tstart, 1);
  blockwrite(cfgfle, tend, 1);
  blockwrite(cfgfle, droploc, 1);
  blockwrite(cfgfle, dropfile, 1);
  writeln('*****FINISHED WRITING TO FILE*****');
  close(cfgfle);
  writeln('*****CONFIG FILE CLOSED, DONE WITH PROGRAM*****')
end.

When I compile and run the program what I get on the screen is this:

***PROGRAM STARTED***
***READING FROM .DAT***
***FINISHED READING***
****MOVED TO BEGINING OF CONFIG FILE****
****FINISHED WRITING TO FILE****
****CONFIG FILE CLOSED, DONE WITH PROGRAM****

and that's it, the computer is locks, I have to ctl-alt-del and restart
the computer.  The program is all done and it locks up.  I'm at a loss
as to why it's doing it.  Any ideas?

Thanks,
CYA,
Christian

Re:Couple Questions...


In article <3395D40A.2...@BIHS.NET> of Wed, 4 Jun 1997 15:46:02 in
comp.lang.pascal.borland, Christian McArthur <cmca...@BIHS.NET> wrote:

Quote
>Howdy all!

>I've been working on figuring ot what's wrong with my code and why the
>program locks up.  I found the least amount needed for it to lock up,
>here it is:

SNIP

Quote
>When I compile and run the program what I get on the screen is this:

SNIP

Quote
>and that's it, the computer is locks, I have to ctl-alt-del and restart
>the computer.  The program is all done and it locks up.  I'm at a loss
>as to why it's doing it.  Any ideas?

Reduce it more?  Running BP7.01 DPMI mode in a Dos box in WfWg3.11, with
a copy of itself as data, I got no lockup; but I did get improper screen
output, including colour changes and unexpected characters.  This
remained on reducing the program to

program BTCONFIG;
uses Crt;

var  cfgfle  : file;
maxplay : byte;

begin
  clrscr;
  writeln('***PROGRAM STARTED***');
  assign(cfgfle, 'BTCONFIG.DAT');
  reset(cfgfle);
  writeln('***READING FROM .DAT***');
  blockread(cfgfle, maxplay, 1);
  writeln('***FINISHED READING***');
  seek(cfgfle, 0);
  writeln('*****MOVED TO BEGINING OF CONFIG FILE*****');
  blockwrite(cfgfle, maxplay, 1);
  writeln('*****FINISHED WRITING TO FILE*****');
  close(cfgfle);
  writeln('*****CONFIG FILE CLOSED, DONE WITH PROGRAM*****')
end.

Changing to   reset(cfgfile, 1);   corrected the output.  However, I
have little experience with block(read/write).
--
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:Couple Questions...


Quote
> I've been working on figuring ot what's wrong with my code and why the
> program locks up.  I found the least amount needed for it to lock up,
> here it is:

program BTCONFIG;
uses Crt;
var  cfgfle  : file;
     btdir   : string;
     droploc : string;
     dropfile: string;
     tstart  : string;
     tend    : string;
     maxplay : byte;
     numbat  : byte;
     tourny  : char;
     Buffer  : array[0..8191] of Byte;
     Res     : integer;
begin
  clrscr; writeln('***PROGRAM STARTED***');
  assign(cfgfle, 'BTCONFIG.DAT'); reset(cfgfle);
  writeln('***READING FROM .DAT***');
  BlockRead (CfgFle,Buffer,SizeOf(Buffer),Res);  { read whole file }
{  At this time, you have all the data read into a buffer in your
program's
memory, and you should be able to parse the individual fields from the
buffer.  I don't know how/why you thing that you can read 1 byte
("btdir")
and work with it as a string variable - but I don't know what the file
data
actually looks like, either.  It seems probable that you don't understand
the file content and its relation to Pascal data types.  The way I would
parse these fields is by determining the offsets into the data for each
one and using Move to assign them to the variables you're declared. }

  blockread(cfgfle, btdir, 1);
{  This makes no sense, in relation to the variable you've declared -
you're reading 1 byte into the "length byte" of a string variable.  I
can't
imagine why you'd want to do that... }
  blockread(cfgfle, maxplay, 1);
  blockread(cfgfle, numbat, 1);
  blockread(cfgfle, tourny, 1);
  blockread(cfgfle, tstart, 1);
  blockread(cfgfle, tend, 1);
  blockread(cfgfle, droploc, 1);
  blockread(cfgfle, dropfile, 1);
{  Here, you've actually read only 8 bytes from the file - did you think
you've done something else? }

  writeln('***FINISHED READING***');
  seek(cfgfle, 0);
  writeln('*****MOVED TO BEGINNING OF CONFIG FILE*****');
  blockwrite(cfgfle, btdir, 1);
  blockwrite(cfgfle, maxplay, 1);
  blockwrite(cfgfle, numbat, 1);
  blockwrite(cfgfle, tourny, 1);
  blockwrite(cfgfle, tstart, 1);
  blockwrite(cfgfle, tend, 1);
  blockwrite(cfgfle, droploc, 1);
  blockwrite(cfgfle, dropfile, 1);
{   Why not change the data in the buffer and (just) write the buffer
data
back to the file?  All you've done here is write 8 bytes of (whatever) to
the first 8 bytes of the file - it hasn't done anything useful that I can
see... }

  writeln('*****FINISHED WRITING TO FILE*****');
  close(cfgfle);
  writeln('*****CONFIG FILE CLOSED, DONE WITH PROGRAM*****')
end.

When I compile and run the program what I get on the screen is this:

***PROGRAM STARTED***
***READING FROM .DAT***
***FINISHED READING***
****MOVED TO BEGINNING OF CONFIG FILE****
****FINISHED WRITING TO FILE****
****CONFIG FILE CLOSED, DONE WITH PROGRAM****

and that's it, the computer is locks, I have to ctl-alt-del and restart
the computer.  The program is all done and it locks up.  I'm at a loss
as to why it's doing it.  Any ideas?

   I really don't know, since I don't have your file to work with and
can't
reproduce the problem.  However, I suspect you're doing this work in the
TP
IDE, and something that's being read/written by your methods is grunging
something in the IDE's memory.  I suggest you compile to Disk and trying
running the .EXE from the DOS command - if it still happens (and you
haven't made the changes I recommend above), I don't know.  There's
nothing obvious here which indicates the potential of your problem.

Re:Couple Questions...


Quote
Mike Copeland wrote:
>   BlockRead (CfgFle,Buffer,SizeOf(Buffer),Res);  { read whole file }
> {  At this time, you have all the data read into a buffer in your
> program's memory, and you should be able to parse the individual
> fields from the buffer.  I don't know how/why you thing that you can
> read 1 byte ("btdir") and work with it as a string variable - but I
> don't know what the file data actually looks like, either.  It seems
> probable that you don't understand the file content and its relation
> to Pascal data types.  The way I would parse these fields is by
> determining the offsets into the data for each one and using Move to
> assign them to the variables you're declared. }

>   blockread(cfgfle, btdir, 1);
> {  This makes no sense, in relation to the variable you've declared -
> you're reading 1 byte into the "length byte" of a string variable.  I
> can't imagine why you'd want to do that... }

It appeats we have two ideas what 'blockread' does.  According to a book
I have (outdated I know but still usefull) and the online help in TP7,
my blockreads would translate to:

  read in from untyped file var 'cfgfle' a value put into variable
'btdir' the first record of the file.

The one refers to how many records to read in, since I'm only reading in
the one vaiable with that statement I want to read in 1 record, not one
1 byte.

CYA,
Christian

Re:Couple Questions...


Quote
Christian McArthur wrote:
> I've been working on figuring ot what's wrong with my code and why the
> program locks up.  I found the least amount needed for it to lock up,
> here it is:
> var  cfgfle  : file;

>      btdir   : string;
> begin
>   clrscr;
>   writeln('***PROGRAM STARTED***');
>   assign(cfgfle, 'BTCONFIG.DAT');
>   reset(cfgfle);
>   writeln('***READING FROM .DAT***');
>   blockread(cfgfle, btdir, 1);
> and that's it, the computer is locks, I have to ctl-alt-del and restart
> the computer.  The program is all done and it locks up.  I'm at a loss
> as to why it's doing it.  Any ideas?

Why don't you turn off I/O checking and check blockread/blockwrite to
see how many records have been written?  See, what you're doing is
opening
the file with a record size of 128, and the data you're reading and
writing
from the file doesn't conform to that...  Sorry about the following
code,
I haven't done any pascal programming for a few years, but it's close:

var numread:word;
begin
  {$i-}
  assign(cfgfle,'BTCONFIG.DAT');
  reset(cfgfle,1); { record size of 1 }
  blockread(cfgfle,btdir,sizeof(btdir),numread);
  if not numread writeln('error reading from file');
  ...
end;

Brian Pape
bp...@ezl.com

Re:Couple Questions...


Quote
Christian McArthur wrote:
> var  cfgfle  : file;
>      maxplay : byte;
>      numbat  : byte;
>      tourny  : char;

> begin
>   blockread(cfgfle, maxplay, 1);
>   blockread(cfgfle, numbat, 1);
>   blockread(cfgfle, tourny, 1);
>   blockread(cfgfle, tstart, 1);

Also, you are trying to read 128 bytes into a 1 byte variable...

do what I said in my previous post, reset the file with a record
size of 1, and then read only the number of bytes you need:

blockread(cfgfle, maxplay, 1, numread);  { numread is optional param
                                           telling how many bytes were
                                           read  }

Brian Pape
bp...@ezl.com

Re:Couple Questions...


Quote
> >   BlockRead (CfgFle,Buffer,SizeOf(Buffer),Res);  { read whole file }
> > {  At this time, you have all the data read into a buffer in your
> > program's memory, and you should be able to parse the individual
> > fields from the buffer.  I don't know how/why you thing that you can
> > read 1 byte ("btdir") and work with it as a string variable - but I
> > don't know what the file data actually looks like, either.  It seems
> > probable that you don't understand the file content and its relation
> > to Pascal data types.  The way I would parse these fields is by
> > determining the offsets into the data for each one and using Move to
> > assign them to the variables you're declared. }

> >   blockread(cfgfle, btdir, 1);
> > {  This makes no sense, in relation to the variable you've declared -
> > you're reading 1 byte into the "length byte" of a string variable.  I
> > can't imagine why you'd want to do that... }

> It appeats we have two ideas what 'blockread' does.  According to a book
> I have (outdated I know but still usefull) and the online help in TP7,
> my blockreads would translate to:

>   read in from untyped file var 'cfgfle' a value put into variable
> 'btdir' the first record of the file.

> The one refers to how many records to read in, since I'm only reading in
> the one vaiable with that statement I want to read in 1 record, not one
> 1 byte.

   No, you are confused here.  BlockRead does indeed work with untyped
files, and it reads as many "records" as have been stated in the Reset
statement.  When you Reset'd the file, you didn't state the "record
size", and it defaulted to 128 bytes (here I made a mistake, since I
stated that every subsequent BlockRead would then read only 1 byte - it
would read _128_ bytes - still not at all what you wanted, I'm sure!).
   In any event, it hardly seems reasonable that you'd really want to use
BlockRead for this file, since it's really a typed file, right?  It seems
more reasonable for typed file I/o, where each Read would read a complete
record, as described in your record Type definition.  Then, it's a simple
"while not EOF...Read" loop to obtain records.
   My original reply was more concerned with doing BlockRead
"(file_var,data_name,1)", where you were attempting to read different
types of data variables with each I/o call, and yet the variables were
not the type of file you opened (and each I/o would read 128 bytes into
each such data field - that all is completely wrong.  I was suggesting
reading in a large chunk of bytes, representing at least a complete
record's amount of data, and parsing the individual fields from the
buffer you read - that's how one processes untyped data, in my
experience.  IOW, you were mixing file types and data records, and I felt
it called for a different approach to untyped file processing.  You
really can't do what you had coded, by trying BlockRead of different
variables with individual BlockReads, which are designed to read a fixed,
stated # of bytes (128 for every BlockRead, in your case) each time.
   So, although I misstated/overlooked the "default record size" issue,
BlockRead isn't what you want to use in your application, rather typed
file I/o ("Read") would do the job.
   There is another issue: some of the data fields defined in your record
are TP/BP strings - unless the file was _created_ by a TP/BP program with
that same definition - and full record I/o was used to write the data
file - the data in those string variables won't/can't be used as string
variables, because the won't be constructed correctly.  They'll either be
simple arrays of character, or the "length byte" will be garbage. Again,
not having access to your file leaves me unable to state what you should
actually be doing, but I am quite sure there's some sort of problem
there...
   I'm sorry about the mistake I posted, but I feel the basics I stated
were correct - individual BlockReads weren't going to accomplish what
your coded seemed to be attempting.  How that locked up your system after
having done what you did, I still don't know...

Other Threads