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 theand 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