Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!inebriae!al
From: al@inebriae.UUCP (Al Evans)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Wanted: Code for simple text interface
Summary: You need a term emulator
Message-ID: <401@inebriae.UUCP>
Date: 31 Jul 89 18:18:36 GMT
References: <9674@phoenix.Princeton.EDU>
Reply-To: al@inebriae.UUCP (Al Evans)
Followup-To: comp.sys.mac.programmer
Distribution: usa
Organization: PowerTools
Lines: 41

In article <9674@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes:
>Here's my problem: I want to be able to open a simple window into which the
>user can type commands.  When he types a character, it is displayed; when he
>types delete, a character is erased; when he types return or enter, the
>entire command is parsed by the program.  Simple enough, right?
>
>When I use TextEdit for the text window, the user is able to go back into the
>stuff already displayed and edit it.  I don't want this.  Besides, I can't
>trap for the return or enter keys easily, and even when I do, I don't know
>how to go back to the beginning of the line and retrieve the whole thing.

Maybe I'm not understanding correctly, but this actually looks to me like
the best way to do what you want. You simply check for the return/enter
keys before posting them to TEKey. You should be able to get the last line
typed from calculations based on nLines and lineStarts in the TERec. In fact,
by adding calculations based on selStart and selEnd, it should be fairly
easy to allow the user to select and execute previously-entered text. In
my opinion, this would be the best way to handle it.

>A simpler way would be to ignore TextEdit.  I can listen for characters and
>echo them to the screen when I get them, and when I get a return or enter, I
>can parse the line.  Scrolling is a tad difficult and unwieldy, but that can
>be overcome.  The problem here is that when the user types delete, the delete
>appears as a *character* on the screen - one of those little white rectangles.

This is a bit more unwieldy, but still fairly easy. Basically, you allocate
a buffer to hold the keystrokes (24X80 or whatever) and write a routine to
draw this buffer on the screen (surely you don't intend to disallow DAs,
etc.!) for updates. You'll probably want to provide a separate (faster)
routine for drawing single characters as they're typed. But you've gotta
CASE on the characters -- when the user types delete, YOU've got to move
the pointer one back in the buffer, do an EraseRect on the character just
deleted, etc. For scrolling, just make the buffer bigger. Is this beginning
to sound like you're reinventing TextEdit? You are. Don't do this unless 
you absolutely HAVE to. [long story about EBCDIC term emulator and blink
attributes omitted, much to the collective relief of the audience]

                                         --Al Evans--
-- 
Al Evans    {tndev,texbell,ssbn}!inebriae!al
            al@inebriae.WLK.COM