Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!mit-eddie!genrad!decvax!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac
Subject: Re: Anchor points and Arrow keys
Message-ID: <19741@ucbvax.BERKELEY.EDU>
Date: Thu, 16-Jul-87 20:22:51 EDT
Article-I.D.: ucbvax.19741
Posted: Thu Jul 16 20:22:51 1987
Date-Received: Sat, 18-Jul-87 09:06:26 EDT
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 39


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.

2.) The Human Interface Guidlines Notes released to devlopers gives
suggested standard behavior for the  and  keys on the big
keyboard. What do keydown events for these keys look like? (Someone
one who has done the experiment, please respond.)

3.) The Human Interface Guildines chapter of Inside Macintosh Volume 4
gives a complete description of what the arrow keys should mean, and
how that meaning should chainge in the presence of shift, command, and
option modifier bits in the event record. Interestingly enough, I have
never seen a product that implements these guidlines. MPW and the
Dialog Manager both mess up in a number of points. Are these
suggestions still the bible?

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 are responsible for updating the scroll bar. Now,
what do you show? At the time your scrollbar update code gets called,
all you have are the current start and end of the selection. If you always
scroll to make the start of the selection visible, then you'll do the
wrong thing for scroll downs. If you always scroll to make the end of
the selection visible, then you'll do the wrong thing for scroll ups.
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.

--- David Phillip Oster            --My Good News: "I'm a perfectionist."
Arpa: oster@dewey.soe.berkeley.edu --My Bad News: "I don't charge by the hour."
Uucp: {seismo,decvax,...}!ucbvax!oster%dewey.soe.berkeley.edu