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: Anchor points and Arrow keys Message-ID: <8481@ut-sally.UUCP> Date: Tue, 14-Jul-87 16:18:43 EDT Article-I.D.: ut-sally.8481 Posted: Tue Jul 14 16:18:43 1987 Date-Received: Thu, 16-Jul-87 06:48:43 EDT Organization: U. Texas CS Dept., Austin, Texas Lines: 59 Keywords: TextEdit selection ranges I'm trying to implement shift-arrow and cmd-shift-arrow (and probably eventually option-shift-arrow) keys in a TextEdit window. The details of how these guys act are discussed in the User Interface chapter of IM-IV. I'm concerned about how to determine where the Anchor point is. What would be best is if the TE record had a field for it, but it doesn't. In case you don't see what the problem is, let me discuss it. Suppose the user uses the mouse to select a range of text sweeping the mouse from the start of the selection to the end. How does one know that the selStart field (of the TE record) is the anchor point and the selEnd field is the active end? Actually, one doesn't, and that's the problem. One solution (the "ideal" solution?) is to act like this: (let the carets beneath the line delimit the selection range) We start with a line with a selection made by the mouse: Anton Nel, recent winner of the prestigious Naumburg Prize, and David Renner ^ ^ and after a cmd-shift-left-arrow: Anton Nel, recent winner of the prestigious Naumburg Prize, and David Renner ^ ^ and after a cmd-shift-right-arrow: Anton Nel, recent winner of the prestigious Naumburg Prize, and David Renner ^ ^ and after another cmd-shift-right-arrow: Anton Nel, recent winner of the prestigious Naumburg Prize, and David Renner ^ ^ In other words, it leaves the original selection there and works around it. Any comments? This seems like the nice thing to do in this situation. Now about implementation... I'm slowly resigning myself to the fact that I'm going to have to keep track of the character that preceded the current character, as well as where the selection range was when we started. I can use this information to help me decide how to collapse selections. As a pleasant side-effect, I can now implement the up & down arrows correctly (as opposed to the way the 128K ROM TextEdit does it) where successive up/down arrow movements stay as close as possible to the original cursor position. (See IM-IV User Interface for that rule.) Any comments on this? Thanks for any assistance. 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