Re: Interrupting Get_Line

[Adam Beneschan <adam@irvine.com>]

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