Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!brian
From: brian@ut-sally.UUCP (Brian H. Powell)
Newsgroups: comp.sys.mac
Subject: Re: Anchor points and Arrow keys
Message-ID: <8503@ut-sally.UUCP>
Date: Fri, 17-Jul-87 13:06:26 EDT
Article-I.D.: ut-sally.8503
Posted: Fri Jul 17 13:06:26 1987
Date-Received: Sat, 18-Jul-87 14:48:56 EDT
References: <19741@ucbvax.BERKELEY.EDU>
Organization: U. Texas CS Dept., Austin, Texas
Lines: 43

In article <19741@ucbvax.BERKELEY.EDU>, oster@dewey.soe.berkeley.edu (David
					Phillip Oster) writes:
< 4.) Brian H. Powell asked about anchor points in regard to these text
< edit points. Brian, you _already_ had to keep track of whether the
< start or end of the text edit record was changing: Suppose the user
< clicks and drags off the edge of the window. The window has to
< auto-scrolll.
...
< You could look at the mouse position relative to the current window,
< but it is more robust just to always keep around the previous
< selection start and end, and compare them against the current to see
< which has changed more.
     I'm not exactly sure what you're describing here, but I'm pretty sure I
disagree.  I look at the mouse position: if the mouse is below the window, I
scroll down a line; if it's above the window, I scroll up a line.  (except of
course for the boundary conditions at the beginning and end of the file.)
TextEdit takes care of the anchor point for me.  If I'm understanding you
correctly, I don't think your solution works if the user has already selected
everything on the current page.  If the user moves the mouse below the window,
the selection hasn't changed so you won't scroll.  But let me reiterate that I
don't really understand exactly what you're describing.


< 1.) Thanks to Apple for fixing the keyboard! On a MacPlus, the shifted
< arrow keys produce an EventRecord identical to the ones produced by
< *,\,-,= on the numeric keypad. On the Mac SE and MacII, the shifted
< arrow keys produce an EventRecord identical to the un-shifted arrow
< keys (same ascii and keycode), but the shift bit is set in the
< modifiers field of the EventRecord. This is just the right thing.
     Thanks for this info.  I agree that Apple has finally done the right
thing.  Does this mean that all future keyboards will be this way?  I hope so,
and I probably plan to assume so.  (No, Apple, don't burn me.)  This probably
opens up a means of supporting shift-arrow keys on all mac keyboards (without
giving up the keypad), but I'll have to think about it for awhile to be sure.


< 3.) The Human Interface Guildines chapter of Inside Macintosh Volume 4
< gives a complete description of what the arrow keys should mean...
< Interestingly enough, I have
< never seen a product that implements these guidlines.
     There are some that come close.  I think Apple made the guidelines before
they tried to implement them.  They are certainly logical semantics, but they
aren't very easy to implement fully.  I'm trying, though.