dave@emerald.PRC.Unisys.COM (David Lee Matuszek) (05/23/89)
Dumb question time.
I'm writing a program that interacts with the user via text
input/output (no flames, please!). Logically, the program looks like:
repeat
write(Question);
read(Answer);
checkAnswer
until done
Now in reality, my program is an event loop, just like it should be.
I have the windows & menus & mousing all working correctly, as well as
the output. But how do I *read* the input line??
I don't want to use a Pascal "read" statement, because this stops the
event loop until the read is completed. This prevents the user from
using the menus, moving windows, and the like. Since the program will
then do another "read" almost immediately, the Mac interface would be
severely disabled. I don't want a modal dialog for the same reasons.
My preference would be to have the user input (typing) go into the
same text window that the program uses for output--just like on a
terminal--and I'd get the line when the user hit Return. I think I
could almost do this, if the user never backspaced, or used cut&paste.
Maybe I'm making the problem to hard by trying to allow these things?
It seems that I should be able to use a modeless dialog (just leaving
it permanently on the screen). If I do, it would contain no text or
anything, just a text entry field. I can't seem to figure out how to
do this, either, and it would mean that the user had to continually
look back and forth between two windows; but it would be better than
nothing.
It can't be this hard, can it? I worked through volume II of
Chernikoff (old edition), and I typed in his editor and understood it
and got it to work. So I know how to make random changes in the
middle of a document. Somehow, though, I can't generalize enough to
figure out how to READ IN A SINGLE LINE! What am I missing?
Sample code would be wonderful, if you have something that does this
(I'm using LSP, but I think I can read C well enough to translate).
Suggestions would be gratefully accepted.
-- Dave Matuszek (dave@prc.unisys.com)
-- Unisys Corp. / Paoli Research Center / PO Box 517 / Paoli PA 19301
-- Any resemblance between my opinions and those of my employer is improbable.
** Fusion now! Remember the Exxon Valdez! **stores@unix.SRI.COM (Matt Mora) (05/25/89)
In article <10387@burdvax.PRC.Unisys.COM> dave@emerald.PRC.Unisys.COM (David Lee Matuszek) writes: >Dumb question time. > >I'm writing a program that interacts with the user via text >input/output (no flames, please!). Logically, the program looks like: > > repeat > write(Question); > read(Answer); > checkAnswer > until done > > >My preference would be to have the user input (typing) go into the >same text window that the program uses for output--just like on a >terminal--and I'd get the line when the user hit Return. I think I >could almost do this, if the user never backspaced, or used cut&paste. >Maybe I'm making the problem to hard by trying to allow these things? > >It seems that I should be able to use a modeless dialog (just leaving >it permanently on the screen). If I do, it would contain no text or >anything, just a text entry field. I can't seem to figure out how to >do this, either, and it would mean that the user had to continually >look back and forth between two windows; but it would be better than >nothing. > i'm not to clear on what you need. Are You using the text window in LSP or a regular window? I Don't see why you can't put both in one window. at the top of the window is a text box where you would display the questions and at the bottom would be the Textedit field for the answer. ________________________________________________________________________ | | | ________________________________________________________ | | | You Could Display your questions here in a text box | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --------------------------------------------------------- | | | | ________________________________________________________ | | | And here could be your textedit field | | | |_______________________________________________________| | ------------------------------------------------------------------------- Or you could use one big textedit filed as big as the window with scroll bars and parse the text of the editrecord for the answer. Maybe I'm missing something but your quextion is not to clear to me. -- ___________________________________________________________ Matthew Mora SRI International stores@unix.sri.com ___________________________________________________________
pepke@loligo.cc.fsu.edu (Eric Pepke) (06/07/89)
This is not really that hard to do, but you have to rethink the problem a little bit. Instead of thinking in terms of the program stopping and reading input, where the program is in control, think in terms of the user deciding when to give information to the program. Have the program maintain an event loop and a TextEdit window, just as you are doing. Define a special key, perhaps the Enter key or Command-Return that, when pressed, sends either the selection range or the line that the insertion point is on to the program. The program then uses a switchboard kind of approach to determine what to do with the text; i.e. it asks itself "What question am I asking now?" and applies the text to the answer. Getting the selection range is easy, and to get the line that the insertion point is on you can, for example, search backward and forward for return characters and the beginning and end of text. I have done something like this in a C program which contains a subset of a Common LISP interpreter. One of the windows is a LISP listener and forms sort of an inside-out development system which is very handy. My problem is trickier, as LISP is not line-oriented, but the principle is the same. (Instead of getting the line that the insertion point is on, I look back and find where the last message from the program ended and read from there to the insertion point.) I am reluctant to give you all of the code, as it is quite a hack and I don't bother, for example, to implement the Edit menu. As David Dunham says, if it doesn't have Undo, it's not a Mac program. However, I will look at it to see if the relevant sections might be extracted and still be meaningful. Most of the rest is just TextEdit. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.