comp.lang.ada
 help / color / mirror / Atom feed
* Interrupting Get_Line
@ 2007-05-31 17:58 mhamel_98
  2007-05-31 18:27 ` Pascal Obry
  0 siblings, 1 reply; 3+ messages in thread
From: mhamel_98 @ 2007-05-31 17:58 UTC (permalink / raw)


I have a program with a task that reads off the command line via
get_line.  Now some other parts/tasks of the program occasionally need
to read off the line as well, usually a (y/n) type question to the
user that I use get_immediate for.  Thing is, the get_line in the cli
task 'intercepts' the response to the get_immediate.  My initial work
around was to have the cli task have a 'get_immediate' entry to
centralize all the command line input in one place, but that does
nothing to break the default entry of the task with the get_line in
it.  Any ideas?

Another workable solution would be to pop up a new console as needed
that goes away as soon as it gets a response, how would I do this?




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

* Re: Interrupting Get_Line
  2007-05-31 17:58 Interrupting Get_Line mhamel_98
@ 2007-05-31 18:27 ` Pascal Obry
  2007-06-01 16:09   ` Adam Beneschan
  0 siblings, 1 reply; 3+ messages in thread
From: Pascal Obry @ 2007-05-31 18:27 UTC (permalink / raw)
  To: mhamel_98

mhamel_98@yahoo.com a �crit :
> I have a program with a task that reads off the command line via
> get_line.  Now some other parts/tasks of the program occasionally need
> to read off the line as well, usually a (y/n) type question to the
> user that I use get_immediate for.  Thing is, the get_line in the cli
> task 'intercepts' the response to the get_immediate. 

I think you have to redesign this stuff. There is a single standard
input and this resource can't be shared by multiple threads. There is no
way to change this fact, it can't be shared and you need to work around
that.

> Another workable solution would be to pop up a new console as needed
> that goes away as soon as it gets a response, how would I do this?

This is OS dependent, it is not related to Ada.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595



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

* Re: Interrupting Get_Line
  2007-05-31 18:27 ` Pascal Obry
@ 2007-06-01 16:09   ` Adam Beneschan
  0 siblings, 0 replies; 3+ messages in thread
From: Adam Beneschan @ 2007-06-01 16:09 UTC (permalink / raw)


On May 31, 11:27 am, Pascal Obry <pas...@obry.net> wrote:
> mhamel...@yahoo.com a écrit :
>
> > I have a program with a task that reads off the command line via
> > get_line.  Now some other parts/tasks of the program occasionally need
> > to read off the line as well, usually a (y/n) type question to the
> > user that I use get_immediate for.  Thing is, the get_line in the cli
> > task 'intercepts' the response to the get_immediate.
>
> I think you have to redesign this stuff. There is a single standard
> input and this resource can't be shared by multiple threads. There is no
> way to change this fact, it can't be shared and you need to work around
> that.

You'll probably also have to do some thinking about how the user is
going to see this.  If the computer asks me for an input line, and I'm
in the middle of typing it but then some other task decides to
interrupt and ask me a question, this is going to be a problem---
particularly if I don't react in time, and I'm still busy typing in my
input to the first question and the input line includes a "y" or "n"
that I accidentally type too late and then get_immediate thinks that's
the answer to the second question.  This kind of problem doesn't solve
itself.  It will require some serious thought about how the interface
should be handled.  There are also issue with what happens to the
first part of the input line when the task butts in with another
question.  Even assuming I don't type in the wrong answer
accidentally, once that question is finished, what happens to the
first one?  Is it abandoned, or do I still have to answer it?  Is the
first part of my previous answer redisplayed on a new line, or does
the cursor move back up to that line?  And am I still able to
backspace over the part of the line I already entered?

The best, if you can do it, is to have a pop-up window that requires
the user to click on a Yes or No button (having it look instead for a
"y" or "n" key is a bad idea for the reason I described above).  If
you can't use a window setup for some reason, I would write a new task
that has an entry to perform a Get_Line (or, probably, an entry to
start a Get_Line and an entry to retrieve the result).  The
implementation of this routine would use Get_Immediate to get each
character and handle backspaces itself.  The task would have another
entry for when the second task needs an immediate Y/N, and then the
body of the task can handle that in whatever way is appropriate, if it
occurs while the Get_Line is still in progress.  There's an issue with
whether you can do a Get_Immediate that waits either for a character
to be typed or for a call to the "interrupt" entry to take place.  You
might have to use the Get_Immediate with an Available OUT parameter,
and poll.

                               -- Adam





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

end of thread, other threads:[~2007-06-01 16:09 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-05-31 17:58 Interrupting Get_Line mhamel_98
2007-05-31 18:27 ` Pascal Obry
2007-06-01 16:09   ` Adam Beneschan

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