Board index » delphi » A PECULIAR PASCAL PROBLEM

A PECULIAR PASCAL PROBLEM

when on a roll of writting a program i came accross this problem and wonder
if anyone else has the same prob.
if i use this command

opt := readkey

all the other "readln" or "readln(x)" commands are not reconized.

i did a trace and it IS reading the line, but just going right by it without
waiting for a user input.

however if i go back to readln(opt) (and not use the readkey command) the
program works fine.
i REALLY NEED  the readkey command cuz of the way the program is designed.

i put a loop in there (for i := 1 to 1000 do begin end;) and that worked for
the most part, til you get to another procedure or function.

any suggestions?

 

Re:A PECULIAR PASCAL PROBLEM


Hi,

on Sun, 02 Jan 2000 at 17:53:02 o'clock, Crystal wrote:

Quote
> if i use this command

> opt := readkey

> all the other "readln" or "readln(x)" commands are not reconized.

> i did a trace and it IS reading the line, but just going right by it without
> waiting for a user input.

> however if i go back to readln(opt) (and not use the readkey command) the
> program works fine.

You have to be more precise. Let me assure you that Readln and ReadKey
can co-exist quite well. Also, ReadKey does wait for user input (assuming
that we are talking about Crt.ReadKey). Note that ReadKey is meant for
getting single characters, while Readln is better used to read Strings,
Integers, etc.

It would probably be most helpful if you could write a mininal program
to reproduce your problem, and post it here. The accompanying code
example works fine on my system (which is not a Borland compiler, but
compatible).

 - Sebastian

--- Begin SNIP message ---
program Rk;

uses
   Crt;

var
   c : Char;
   s : String;

begin
   c := ReadKey;
   Writeln(c);
   Readln(s);
   Writeln(s);
   c := ReadKey;
   Writeln(c);
   Readln(s);
   Writeln(s);
end.
--- End SNIP message ---

--
If you read this text, your newsreader doesn't support signature frames.

Re:A PECULIAR PASCAL PROBLEM


Hi sebastian
good point
i'm making a black jack game for work (hehehe, guys there are bored witht he
solitary game, but dont want anything fancy just something small to tinker
with. there are other variables that they would like that are not offered
with the cmoercial software that i can produce)
anyways....

my option routine works as such:

repeat
    opt := readkey;
    opt := ucase(opt);
until opt in ['H','S','I','D' etc. . .]

case opt of
    'H': PlayerHit;
    'S': PlayerStand;
end;

the above works fine so far when running
i use readln alot as a pause in the routine to look what it does while i run
it (yes i could use a break method but i've used this method for years)

when playerstand is executed. that works fine
when i get to the compare hands routine i want to see the results (for debug
purposes) so i use the writeln ('player wins') or writeln('dealer wins')
etc... and have a :

writeln . . .etc...
readln;
halt;

all my other programs work fine when using this method with the exception of
this one.
the trace (F8 & F7) shows it reading it, but will not wait for the readln
commend (yes i did use a readln( some variable) but that didnt work either)
it just goes right to the halt then the program promptly halts. so even if i
WANTED the user to input something there, the program would just ignore it.

hope this sheds some light on the situation

thanx in advance
Crys

Quote
Sebastian Koppehel wrote in message ...
>Hi,

>on Sun, 02 Jan 2000 at 17:53:02 o'clock, Crystal wrote:

>> if i use this command

>> opt := readkey

>> all the other "readln" or "readln(x)" commands are not reconized.

>> i did a trace and it IS reading the line, but just going right by it
without
>> waiting for a user input.

>> however if i go back to readln(opt) (and not use the readkey command) the
>> program works fine.

>You have to be more precise. Let me assure you that Readln and ReadKey
>can co-exist quite well. Also, ReadKey does wait for user input (assuming
>that we are talking about Crt.ReadKey). Note that ReadKey is meant for
>getting single characters, while Readln is better used to read Strings,
>Integers, etc.

>It would probably be most helpful if you could write a mininal program
>to reproduce your problem, and post it here. The accompanying code
>example works fine on my system (which is not a Borland compiler, but
>compatible).

> - Sebastian

>--- Begin SNIP message ---
>program Rk;

>uses
>   Crt;

>var
>   c : Char;
>   s : String;

>begin
>   c := ReadKey;
>   Writeln(c);
>   Readln(s);
>   Writeln(s);
>   c := ReadKey;
>   Writeln(c);
>   Readln(s);
>   Writeln(s);
>end.
>--- End SNIP message ---

>--
>If you read this text, your newsreader doesn't support signature frames.

Re:A PECULIAR PASCAL PROBLEM


Quote
> i'm making a black jack game for work (hehehe, guys there are bored witht he
> solitary game, but dont want anything fancy just something small to tinker
> with. there are other variables that they would like that are not offered
> with the cmoercial software that i can produce)
> anyways....

> my option routine works as such:

> repeat
>     opt := readkey;
>     opt := ucase(opt);
> until opt in ['H','S','I','D' etc. . .]
> case opt of
>     'H': PlayerHit;
>     'S': PlayerStand;
> end;

> the above works fine so far when running

   This should be coded as follows:
car C1,C2 : char;
repeat
  C1 := UpCase(ReadKey);
  case C1 of
   #00 : C2 := ReadKey;  { special/extended key - flush scan code }
   #27 : ;                                            { loop exit }
   'H' : PlayerHit;
   'S' : PlayerStand;
   else
  end  { Case }
until C1 = #27  { Escape }

Quote
> i use readln alot as a pause in the routine to look what it does while i run
> it (yes i could use a break method but i've used this method for years)

   You will be able to use Read/Readln with this (in any of the called
subprograms which process the action), but this should be the root of
your program's main processing.

Quote
> when playerstand is executed. that works fine
> when i get to the compare hands routine i want to see the results (for debug
> purposes) so i use the writeln ('player wins') or writeln('dealer wins')
> etc... and have a :

> writeln . . .etc...
> readln;
> halt;

   The Halt and dummy Readln shouldn't be necessary.  Using the Readln to
display the screen in the IDE is sloppy and ignores the Alt-F5 feature.  
Halt is always a poor substitution for good design and understanding of
the language you're using.

Quote
> all my other programs work fine when using this method with the exception of
> this one.
> the trace (F8 & F7) shows it reading it, but will not wait for the readln
> commend (yes i did use a readln( some variable) but that didnt work either)
> it just goes right to the halt then the program promptly halts. so even if i
> WANTED the user to input something there, the program would just ignore it.

   One must always be careful to assure proper and full use of ReadKey -
special or extended keys must be dealt with as above...or strange actions
with subsequent keyboard I/o can occur.

Re:A PECULIAR PASCAL PROBLEM


Hi,

on Sun, 02 Jan 2000 at 20:34:15 o'clock, Crystal wrote:

Quote
> my option routine works as such:

> repeat
>     opt := readkey;
>     opt := ucase(opt);
> until opt in ['H','S','I','D' etc. . .]

That's like I normally do it too.

Quote
> the above works fine so far when running
> i use readln alot as a pause in the routine to look what it does while i run
> it (yes i could use a break method but i've used this method for years)

<snip>

Quote
> it just goes right to the halt then the program promptly halts. so even if i
> WANTED the user to input something there, the program would just ignore it.

I suspect that there is still a carriage return in the keyboard queue.
You can secure that this is not the case by changing your test to

   while KeyPressed do ReadKey;
   Readln;

Note that you also can use ReadKey to prompt for a keypress before halting
the program. This wouldn't solve your problem, but at least fix your
program for the time being.

 - Sebastian

--
Signature optimized for 1024x786 resolution in fullscreen mode.

Re:A PECULIAR PASCAL PROBLEM


JRS:  In article <84lof5$jp...@sword.avalon.net> of Sat, 1 Jan 2000
14:34:15 in news:comp.lang.pascal.borland, Crystal <kswhitew...@usa.net>
wrote:

Quote
>my option routine works as such:

>repeat
>    opt := readkey;
>    opt := ucase(opt);
>until opt in ['H','S','I','D' etc. . .]

>case opt of
>    'H': PlayerHit;
>    'S': PlayerStand;
>end;

It occurs to me that the following skeleton may be better, since it is
more auto-self-consistent :

repeat
  OK := true ;
  case(UpCase(ReadKey)) of
    'H': ... ;
    'S': ... ;
    else OK := false ;
  until OK ;

Of course, one still needs to make the Prompt and the Help consistent.

Perhaps one should follow the TurboVision example of nested function
calls for menus, with each individual function having parameters for
prompt part, key, help, action.

--
? John Stockton, Surrey, UK.  j...@merlyn.demon.co.uk   Turnpike v4.00   MIME. ?
 <URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
 <URL: ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ;
 <URL: http://www.merlyn.demon.co.uk/clpb-faq.txt> Pedt Scragg: c.l.p.b. mFAQ.

Re:A PECULIAR PASCAL PROBLEM


In article <MPG.12d8357d61ae6081989...@news.primenet.com>,

Quote
Mike Copeland <mrc...@primenet.com> wrote:
>Halt is always a poor substitution for good design and understanding of
>the language you're using.

Here I disagree strongly. Halt is a very good way to deal with various
errors. (assuming one wants to halt the program.) Also Halt allows you
to give exit code.

Osmo

Re:A PECULIAR PASCAL PROBLEM


Quote
Osmo Ronkanen <ronka...@cc.helsinki.fi> wrote in message
> Mike Copeland <mrc...@primenet.com> wrote:
> >Halt is always a poor substitution for good design and understanding of
> >the language you're using.

And algorithm of a program.

Quote
> Here I disagree strongly. Halt is a very good way to deal with various
> errors. (assuming one wants to halt the program.) Also Halt allows you
> to give exit code.

That is right. I also use it. But, it solves little number of problems. When
you call Halt "directly", you need to deallocate memory, close all opened
files, close graphic mode, do some uninitializations, .... OK, Pascal does
some of these things for us. So, we need to write our ExitProc, and that
brings us to what Mike said: Our code becomes unreadable anymore, and it
isn't very linear as it should be. Some nice solutions for dealing with
errors are:
* SetJmp/LongJmp in Modula-2 (I think this also exists in C)
* try...finally/except...end in Delphi (I like this most of all others)
* goto in TMT (you can jump out to some of parent procedures).
There are many, many parts of programs which need _handling_ of different
errors and not just killing program.

Alexa

Re:A PECULIAR PASCAL PROBLEM


Quote
> * SetJmp/LongJmp in Modula-2 (I think this also exists in C)
> * try...finally/except...end in Delphi (I like this most of all others)
> * goto in TMT (you can jump out to some of parent procedures).
> There are many, many parts of programs which need _handling_ of different
> errors and not just killing program.

To complete the `cultural tour', one can cite the Ada model where
you can raise exceptions, catch, re-raise at other levels, attach messages
etc. No more details, otherwise Osmo will be very angry. Browsable example
from link below...

--
Gautier

_____\\________________\_______\____________
http://members.xoom.com/gdemont/unzipada.htm

Other Threads