Board index » delphi » Detecting q key after error input.

Detecting q key after error input.

In article <3A80C4C1.3B740...@thegrid.net>,
Patrick D. Rockwell <prockw...@thegrid.net> wrote:

Quote
>Consider the following program.

>program badnum;
>{$I-}
>var i:integer;
>    s:string;
>begin
>  repeat
>    read(i);
>    writeln('I = ',i:3);
>    if(ioresult<>0) then read(s);

This does not work if there second read also causes an error. You need
to take all possibilities into consideration.

Quote
>    writeln('S = ',s);
>  until i=13;
>{$I+}
>end.

>Below is a similar program, but it uses readln instead of read, and it
>doesn't allow for more than one character on one line.

>Pascal gives an easy way of dealing with non-numeric input, but let's
>say
>that I wanted to quit this loop, not with the number 13, but with the
>letter
>q. Any other letter will give an error message, but let's say that I
>want
>only q to quit the loop. How do I make the program tell if Q or q was
>entered? I've tried readkey and keypressed, but those don't do what I
>want.

Read the whole thing as a string and parse it. The following extracts
the first element (separated by spaces) from st1 into st2. Then use
Val() to convert it.

Procedure ExtractWord(var st1,st2:openstring);
var i:integer;
begin
  Trim(st1);
  if st1='' then st2:=''
    else begin
      i:=1;
      while (i<=length(st1)) and (st1[i]>' ') do inc(i);
      if i>length(st1) then begin
                             st2:=st1;
                             st1:='';
                            end
                 else begin
                        st2:=copy(st1,1,i-1);
                        st1:=copy(st1,i+1,255);
                        trim(st1);
                      end;
    end;
end;

Procedure Trim(var str:openstring);
var i:integer;
begin
  if length(st)>0 then
     begin
       i:=1;
       While  (i<length(st)) and (st[i]<=' ') do inc(i);
       Delete(st,1,i-1);
       i:=length(st);
       While (i>0) and (st[i]<=' ') do dec(i);
       st[0]:=chr(i);
     end;
end;

For TP before 7.0 use string as the parameter type.

Osmo

 

Re:Detecting q key after error input.


Quote
Osmo Ronkanen wrote:
> In article <3A80C4C1.3B740...@thegrid.net>,Read the whole thing as a
> string and parse it. The following extracts
> the first element (separated by spaces) from st1 into st2. Then use
> Val() to convert it.

Well, that would work. I've done that before, but what I'd really like is a
way of detecting which
non-numeric key caused an I/O error in a numeric input. There MUST be some
kind of interrupt or
memory location which can do that. What about the textrec type? Also, I'm
still hoping that someone
can tell me the location or pointer to the location of the command buffer
(which I previously referred to
incorrectly as the keyboard buffer).

--
Patrick D. Rockwell
mailto:prockw...@thegrid.net
mailto:HNHC...@prodigy.net
mailto:patri48...@aol.com

Re:Detecting q key after error input.


In article <3A81AB39.8EC1C...@thegrid.net>,
Patrick D. Rockwell <prockw...@thegrid.net> wrote:

Quote
>Osmo Ronkanen wrote:

>> In article <3A80C4C1.3B740...@thegrid.net>,Read the whole thing as a
>> string and parse it. The following extracts
>> the first element (separated by spaces) from st1 into st2. Then use
>> Val() to convert it.

>Well, that would work. I've done that before, but what I'd really like is a
>way of detecting which
>non-numeric key caused an I/O error in a numeric input. There MUST be some
>kind of interrupt or
>memory location which can do that.

Come on, you want to do it the ugly way? That makes no sense.

Osmo

Re:Detecting q key after error input.


Quote
Osmo Ronkanen wrote:
> In article <3A81AB39.8EC1C...@thegrid.net>,
> Patrick D. Rockwell <prockw...@thegrid.net> wrote:
> >Osmo Ronkanen wrote:

> >> In article <3A80C4C1.3B740...@thegrid.net>,Read the whole thing as a
> >> string and parse it. The following extracts
> >> the first element (separated by spaces) from st1 into st2. Then use
> >> Val() to convert it.

> >Well, that would work. I've done that before, but what I'd really like is a
> >way of detecting which
> >non-numeric key caused an I/O error in a numeric input. There MUST be some
> >kind of interrupt or
> >memory location which can do that.

> Come on, you want to do it the ugly way? That makes no sense.

Well, for the program that I'm writing, I might not need this, but I'm really
interested in knowing as much about memory locations and interrupts as possible,
for future reference, or if nothing else, for my
own curiosity. I can't believe that there is no way to tell which key triped an
error 106. Is there anyone .with an idea???

--
Patrick D. Rockwell
mailto:prockw...@thegrid.net
mailto:HNHC...@prodigy.net
mailto:patri48...@aol.com

Re:Detecting q key after error input.


In article <3A821F92.4754B...@thegrid.net>,

Quote
  prockw...@thegrid.net wrote:
> ... I can't believe that there is no way to tell which key triped an
> error 106. Is there anyone .with an idea???

I can believe it. Your not going to get much more than a 106 from read
or readln. The solution has already been given but I would go further
and say write your own keyboard input routine for strings. When you do
you can specify which characters are allowed and which aren't. When a
special key such as escape, enter or a function key is pressed your
routine can handle it in whatever fashion is apropriate. Writing
your own routine may take some effort, but really IMHO read and readln
for keyboard input are wholly inadequate.

Quote

> --
> Patrick D. Rockwell
> mailto:prockw...@thegrid.net
> mailto:HNHC...@prodigy.net
> mailto:patri48...@aol.com

Regards Hanford

Sent via Deja.com
http://www.deja.com/

Re:Detecting q key after error input.


Quote
h_c...@my-deja.com wrote:
> In article <3A821F92.4754B...@thegrid.net>,
>   prockw...@thegrid.net wrote:
> > ... I can't believe that there is no way to tell which key triped an
> > error 106. Is there anyone .with an idea???

> I can believe it. Your not going to get much more than a 106 from read
> or readln. The solution has already been given but I would go further

You mean the readkey suggestion?

Quote
> and say write your own keyboard input routine for strings. When you do
> you can specify which characters are allowed and which aren't. When a
> special key such as escape, enter or a function key is pressed your
> routine can handle it in whatever fashion is apropriate. Writing
> your own routine may take some effort, but really IMHO read and readln
> for keyboard input are wholly inadequate.

Yes, I've written routines which do that.But I still think that somewhere
in the computers memory is the
record of the last key struck before the return key was hit.Could it be
the textrec variable? The command buffer? I wish someone knew where the
command buffer was.

--
Patrick D. Rockwell
mailto:prockw...@thegrid.net
mailto:HNHC...@prodigy.net
mailto:patri48...@aol.com

Re:Detecting q key after error input.


Quote
In article <3A825BE5.F8BEA...@thegrid.net>, Patrick D. Rockwell wrote:
>h_c...@my-deja.com wrote:

>> In article <3A821F92.4754B...@thegrid.net>,
>>   prockw...@thegrid.net wrote:
>> > ... I can't believe that there is no way to tell which key triped an
>> > error 106. Is there anyone .with an idea???

>> I can believe it. Your not going to get much more than a 106 from read
>> or readln. The solution has already been given but I would go further

>You mean the readkey suggestion?

Probably yes, and I would also recommend that.

Quote
>> and say write your own keyboard input routine for strings. When you do
>> you can specify which characters are allowed and which aren't. When a
>> special key such as escape, enter or a function key is pressed your
>> routine can handle it in whatever fashion is apropriate. Writing
>> your own routine may take some effort, but really IMHO read and readln
>> for keyboard input are wholly inadequate.

>Yes, I've written routines which do that.But I still think that somewhere
>in the computers memory is the
>record of the last key struck before the return key was hit.

1. Who says it is a key? Standard input could have been piped in.
2. Only the last key would be held -> "return"

Quote
>Could it be in the textrec variable.

Yes and no. Textrec only contains the functions that do the actual input
output processing (allowing e.g. Crt to take over).

No, you can't get that info for there, and the standard one doesn't even
save that data.

Yes, because you could write your own. See Swag sources or Crt's source for
examples.

Quote
>The command buffer? I wish someone knew where the command buffer was.

Command buffer? What do you want with that?

Other Threads