🚀 go-pugleaf

     I sent a letter to Apple concerning several topics, one of which was a
request for any information on how to get the anchor point info out of
TextEdit.  I got a rather unusual reply, which I think needs some discussion.

>Brian,
>     As a general rule, your application should not take any explicit action
>when special keys are pressed.  Instead, your application should just pass the
>key on to TextEdit.  This way, when we develop new keyboards (or alternate
>input devices), we will also update TextEdit to handle the new keys.
>     For example, TextEdit now handles the arrow keys correctly.  If you
>handle the arrow keys yourself, not only are you relying on the character or
>key codes of the arrow keys remaining unchanged, but you will also be changing
>the functionality of TextEdit with which users are already familiar.

     It's news to me that TextEdit now handles the arrow keys correctly.  It
handles left and right arrow correctly.  It does not handle up and down arrow
correctly, and it doesn't handle the arrows with any of the modifier keys
pressed.  (If we neglect the option-key, which has application-specified
semantics, there are 16 cases to handle (four arrows * no modifiers, shift,
cmd, and cmd-shift).  Apple got two of them right in TextEdit.)  Be sure to
read the User Interface chapter of Inside Mac, Volume IV, to learn the proper
actions to be taken by the arrow keys.  If you think about it, TextEdit isn't
powerful enough to implement those guidelines; they'd need two or three more
fields in the TERecord to do it right.
     And then there's the fact that TE on a 128K Mac (and the Lisa) doesn't
handle arrows at all, but I don't think Apple really cares about that.
     If Apple changes the character codes returned by the event manager for
the arrow keys, my program will not be the only program to break.  What about
all those programs that don't use TextEdit and still try to use the arrow
keys.  Several such programs come to mind:  MS-Word, MacWrite, spreadsheets,
programming language editors, ...  I'm not saying that Apple should set the
character codes in stone, but get real:  a lot of programs are going to break,
and I don't mind if mine is one of them.  I'll take that chance.
     As for the key-codes.  I really doubt they'll stay the same.  But
somehow, I've got to implement shift-arrow and cmd-shift-arrow, and the 64K
and 128K ROMs (or is it the keyboard 8021 ROMs?) return certain mathematical
symbols (consult your numeric keypad) for those keydowns.  (Actually, the
Mac-Plus works right for cmd-shift-arrow, but not shift-arrow.  The 64K Rom
macs don't get either right.)  Sooo, my program checks the ROM version number,
and if it finds a 64K or 128K ROM, it consults the key-code, otherwise it
takes the event manager's word that the character-code is right.
     As for users being familiar with TextEdit, that's not the point.  The
point, last time I checked, was to implement the Mac User Interface
guidelines.  (Or did the U.S.S.R. take over North America?  I didn't get to
see the news last night.)

     Let's continue with the letter:

>     When shift-clicking to extend a selection range, TextEdit considers the
>selStart point to be the "anchor".  If the user shift-clicks within the
>current selection, the selection is reduced to be from selStart to the click
>location.  If the user shift-clicks past the end of the range, then the new
>selection is also selStart to the click location.
>     Only if the user shift-clicks before the start of the selection are
>things different.  Then the new selection range extends from the click
>location to selEnd.
>
>				I hope this helps,
>
>				Chris Derossi
>				Developer Tech Support Technoid

     I disagree with this behavior, but I live with it.  Shift-Clicks before
the anchor point should select from the click to the anchor point.
Shift-Clicks after the anchor point should select from the anchor point to the
click.  Remember, IM-IV, p. IV-5 says "Once selection begins, the anchor point
cannot be moved except by beginning a new selection."  
     To fix this, you have to do some nastiness inside your clik_loop.  (You
are using your own clik_loop, aren't you?  Surely you're not using the ROM's.)
I don't think it would be worth it to change this behavior.  (Actually, I may
try it, just to see if it works.)

     I've got 8 pages of C code that handles keyboard input.  Most of it
addresses, you guessed it, arrow keys.  It's a pain to implement them in
TextEdit, but it can be done.  I may put together a medium-sized posting which
discusses some of the finer points.

Brian H. Powell
		UUCP:	{ihnp4,seismo,ctvax}!ut-sally!brian
		ARPA:	brian@sally.UTEXAS.EDU

   _Work_					 _Not Work_
  Department of Computer Sciences		P.O. Box 5899
  Taylor Hall 2.124				Austin, TX 78763-5899
  The University of Texas at Austin		(512) 346-0835
  Austin, TX 78712-1188
  (512) 471-9536