comp.lang.ada
 help / color / mirror / Atom feed
* Re: Text_IO.Get_Line
  1997-05-17  0:00 Text_IO.Get_Line RE Hixon
@ 1997-05-17  0:00 ` Robert Dewar
  1997-05-19  0:00   ` Text_IO.Get_Line RE Hixon
  1997-05-22  0:00   ` Text_IO.Get_Line RE Hixon
  1997-05-18  0:00 ` Text_IO.Get_Line Matthew Heaney
  1 sibling, 2 replies; 8+ messages in thread
From: Robert Dewar @ 1997-05-17  0:00 UTC (permalink / raw)



RE Hixon says

<<This may have a simple fix, but it has me perplexed.  I have used several
different Ada compilers (Ada 83 and 95) on different types of Intel based
systems and keep getting the same results.  When I use Get_Line and enter
more characters than the specified string will hold; the remaining
characters stay in the input buffer waiting for the next Get.  This causes
an exception to occur.  My fix is to execute a Skip_Line after each
Get_Line, but this seems inefficient.  Any ideas, or reasons why I am
getting these results?>>

I don't quite understand what is perplexing you, but the behavior you
describe as perplexing is exactly what is required in the Ada 95 RM, so
it is hardly surprising that "several different Ada compilers" behave the
same way. (Ada 83 is the same as Ada 95 here).

Perhaps you could describe what you want to achieve, and then maybe we
can suggest how to program it using the features in Ada :-)





^ permalink raw reply	[flat|nested] 8+ messages in thread

* Text_IO.Get_Line
@ 1997-05-17  0:00 RE Hixon
  1997-05-17  0:00 ` Text_IO.Get_Line Robert Dewar
  1997-05-18  0:00 ` Text_IO.Get_Line Matthew Heaney
  0 siblings, 2 replies; 8+ messages in thread
From: RE Hixon @ 1997-05-17  0:00 UTC (permalink / raw)



This may have a simple fix, but it has me perplexed.  I have used several
different Ada compilers (Ada 83 and 95) on different types of Intel based
systems and keep getting the same results.  When I use Get_Line and enter
more characters than the specified string will hold; the remaining
characters stay in the input buffer waiting for the next Get.  This causes
an exception to occur.  My fix is to execute a Skip_Line after each
Get_Line, but this seems inefficient.  Any ideas, or reasons why I am
getting these results?

Russell E. Hixon, USAF                    COMM   601.377.0520
Master Instructor                               FAX       601.377.1252
333rd Training Squadron                    EMAIL   REHixon@aol.com




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Text_IO.Get_Line
  1997-05-17  0:00 Text_IO.Get_Line RE Hixon
  1997-05-17  0:00 ` Text_IO.Get_Line Robert Dewar
@ 1997-05-18  0:00 ` Matthew Heaney
  1 sibling, 0 replies; 8+ messages in thread
From: Matthew Heaney @ 1997-05-18  0:00 UTC (permalink / raw)



In article <19970517194301.PAA19410@ladder02.news.aol.com>, rehixon@aol.com
(RE Hixon) wrote:

>This may have a simple fix, but it has me perplexed.  I have used several
>different Ada compilers (Ada 83 and 95) on different types of Intel based
>systems and keep getting the same results.  When I use Get_Line and enter
>more characters than the specified string will hold; the remaining
>characters stay in the input buffer waiting for the next Get.  This causes
>an exception to occur.  My fix is to execute a Skip_Line after each
>Get_Line, but this seems inefficient.  Any ideas, or reasons why I am
>getting these results?

This is expected behavior.  Get_Line only returns as many characters as can
be contained in the buffer you've declared to hold the input string.

The simplest way of detected whether you've read all of the input
characters is to compare Last (one one the return values of Get_Line) to
Buffer'Last: if Last < Buffer'Last, this means you've read the entire
string.

If you want to save the entire input string (not throw the end of it away
with Skip_Line), then copy each segment you read using Get_Line into an
Unbounded_String:

declare
   The_Line : Ada.Strings.Unbounded.Unbounded_String;
   The_Line_Segment : String (1 .. 80);
   Last : Natural;
begin
   Get_Entire_Line:
   loop
      Text_IO.Get_Line (The_Line_Segment, Last);
      Append (The_Line, New_Item => The_Line_Segment (1 .. Last));
      exit Get_Entire_Line when Last < The_Line_Segment'Last;
   end loop Get_Entire_Line;
end;

You could also use a recursive solution:

declare
   function Get_Line return String is
      The_Line : String (1 .. 80);
      Last : Natural;
   begin
      Text_IO.Get_Line (The_Line, Last);
      if Last < The_Line'Last then
         return The_Line (1 .. Last);
      else
         return The_Line & Get_Line;
      end if;
   end Get_Line;

   The_Line : constant String := Get_Line;
begin
...


Hope that helps,
Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Text_IO.Get_Line
  1997-05-19  0:00   ` Text_IO.Get_Line RE Hixon
@ 1997-05-19  0:00     ` Matthew Heaney
  0 siblings, 0 replies; 8+ messages in thread
From: Matthew Heaney @ 1997-05-19  0:00 UTC (permalink / raw)



In article <19970519224400.SAA06280@ladder02.news.aol.com>, rehixon@aol.com
(RE Hixon) wrote:

>Thanks for your reply concerning Get_Line.  In MASM 6.1, when I request a
>buffered string input, the system will only allow the user to enter the
>maximum number of characters that I have allowed to be stored in memory. 
>If the user trys to enter more than what I have declared, the system will
>beep and not allow any more input.  I would like to duplicate this using
>Ada 95.

But the point is that that doesn't necessarily need to be a restriction. 
It's a restriction because you have made the choice that it be a
restriction.

As shown in the previous post, using a loop to read all the line, and
appending each segment to an unbounded_string, means the restriction need
not be there.  Of course, you may have other reasons for the restriction,
but "size of the internal buffer" doesn't need to be one.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Text_IO.Get_Line
  1997-05-17  0:00 ` Text_IO.Get_Line Robert Dewar
@ 1997-05-19  0:00   ` RE Hixon
  1997-05-19  0:00     ` Text_IO.Get_Line Matthew Heaney
  1997-05-22  0:00   ` Text_IO.Get_Line RE Hixon
  1 sibling, 1 reply; 8+ messages in thread
From: RE Hixon @ 1997-05-19  0:00 UTC (permalink / raw)



Thanks for your reply concerning Get_Line.  In MASM 6.1, when I request a
buffered string input, the system will only allow the user to enter the
maximum number of characters that I have allowed to be stored in memory. 
If the user trys to enter more than what I have declared, the system will
beep and not allow any more input.  I would like to duplicate this using
Ada 95.


Russell E. Hixon, USAF                    COMM   601.377.0520
Master Instructor                               FAX       601.377.1252
333rd Training Squadron                    EMAIL   REHixon@aol.com




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Text_IO.Get_Line
  1997-05-17  0:00 ` Text_IO.Get_Line Robert Dewar
  1997-05-19  0:00   ` Text_IO.Get_Line RE Hixon
@ 1997-05-22  0:00   ` RE Hixon
  1997-05-22  0:00     ` Text_IO.Get_Line Nick Roberts
  1997-05-25  0:00     ` Text_IO.Get_Line Jerry van Dijk
  1 sibling, 2 replies; 8+ messages in thread
From: RE Hixon @ 1997-05-22  0:00 UTC (permalink / raw)



In your last message you suggested using Get_Immediate.  According to all
my sources here it should work exactly the way that I want.  I only have
one problem -- it doesn't.  Cohen states in his book, Ada as a Second
Language, p. 769, that "Get_Immediate works just like the Character
version of Get, except that if the underlying operating system allows it,
unbuffered input is used."  I guess that DOS 6.22 and Win 95 are two of
those operating systems that do not allow unbuffered input.  On both
systems using GNAT 3.07, Get_Immediate did not recognize the character
input without pressing the ENTER key.  Do you have any other suggestions
or ideas that would allow me to create interactive input using Ada 95
and/or limiting the number of characters that a user can enter?  Thanks in
advance.
Russell E. Hixon, USAF                    COMM   601.377.0520
Master Instructor                               FAX       601.377.1252
333rd Training Squadron                    EMAIL   REHixon@aol.com




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Text_IO.Get_Line
  1997-05-22  0:00   ` Text_IO.Get_Line RE Hixon
@ 1997-05-22  0:00     ` Nick Roberts
  1997-05-25  0:00     ` Text_IO.Get_Line Jerry van Dijk
  1 sibling, 0 replies; 8+ messages in thread
From: Nick Roberts @ 1997-05-22  0:00 UTC (permalink / raw)





RE Hixon <rehixon@aol.com> wrote in article
<19970522184500.OAA10276@ladder02.news.aol.com>...
> In your last message you suggested using Get_Immediate.  According to all
> my sources here it should work exactly the way that I want.  I only have
> one problem -- it doesn't.  Cohen states in his book, Ada as a Second
> Language, p. 769, that "Get_Immediate works just like the Character
> version of Get, except that if the underlying operating system allows it,
> unbuffered input is used."  I guess that DOS 6.22 and Win 95 are two of
> those operating systems that do not allow unbuffered input.  On both
> systems using GNAT 3.07, Get_Immediate did not recognize the character
> input without pressing the ENTER key.  Do you have any other suggestions
> or ideas that would allow me to create interactive input using Ada 95
> and/or limiting the number of characters that a user can enter?  Thanks
in
> advance.


Yes, I do. The problem (I reckon) is that GNAT is still using _cooked_
input. You want uncooked. To do this you must call the DOS function called
'IOCTL'. How you do this, I'm not sure, to be honest. But, ultimately, you
want to put 16#44# (function number 68) in the AH register, 16#01#
(subfunction 1) in AL, the file handle (for keyboard input - usually 0) in
BX, and 2#0000_0000_0010_0000# in DX, and then call interrupt 16#21#. You
may want to test the C (carry) flag on return - it is set for error, and 0
for OK.

I'll have a look at the GNAT documentation to see if it provides a facility
for calling (DOS) interrupts.  In the meantime: try for yourself! Post us
(or mail me) how you get on. Good luck.

Nick.





^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Text_IO.Get_Line
  1997-05-22  0:00   ` Text_IO.Get_Line RE Hixon
  1997-05-22  0:00     ` Text_IO.Get_Line Nick Roberts
@ 1997-05-25  0:00     ` Jerry van Dijk
  1 sibling, 0 replies; 8+ messages in thread
From: Jerry van Dijk @ 1997-05-25  0:00 UTC (permalink / raw)



In article <19970522184500.OAA10276@ladder02.news.aol.com> rehixon@aol.com writes:

>                               I guess that DOS 6.22 and Win 95 are two of
>those operating systems that do not allow unbuffered input.  On both
>systems using GNAT 3.07, Get_Immediate did not recognize the character
>input without pressing the ENTER key.

GNAT 3.07 for DOS does not implement the behaviour you want. Use the
input functions in EZ2LOAD's CONIO (console I/O) library instead.

Note that GNAT3.09 for Win95 does work as you expected.

--

-- Jerry van Dijk       | Leiden, Holland
-- Consultant           | Team Ada
-- Ordina Finance       | jdijk@acm.org




^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~1997-05-25  0:00 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-05-17  0:00 Text_IO.Get_Line RE Hixon
1997-05-17  0:00 ` Text_IO.Get_Line Robert Dewar
1997-05-19  0:00   ` Text_IO.Get_Line RE Hixon
1997-05-19  0:00     ` Text_IO.Get_Line Matthew Heaney
1997-05-22  0:00   ` Text_IO.Get_Line RE Hixon
1997-05-22  0:00     ` Text_IO.Get_Line Nick Roberts
1997-05-25  0:00     ` Text_IO.Get_Line Jerry van Dijk
1997-05-18  0:00 ` Text_IO.Get_Line Matthew Heaney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox