Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!brian From: brian@ut-sally.UUCP (Brian H. Powell) Newsgroups: comp.sys.mac Subject: TextEdit problem Message-ID: <8424@ut-sally.UUCP> Date: Mon, 6-Jul-87 18:29:57 EDT Article-I.D.: ut-sally.8424 Posted: Mon Jul 6 18:29:57 1987 Date-Received: Wed, 8-Jul-87 00:40:09 EDT Organization: U. Texas CS Dept., Austin, Texas Lines: 87 My apologies if this has been discussed before, but I've run into what appears to be a TextEdit bug, and I'm trying to decide what to do about it. I'm working on a program which has (among other things) a window for editing plain text. I just use TextEdit to handle the editing. (i.e., there are no fancy display procedures, fancy mousedown procedures, etc.) A problem sometimes occurs when I cut text. The display gets confused. Updating the window changes the appearance, but it's still not correct. The program behaves differently on the two machines I'm testing it on: a 128K Mac with Finder 4.1, and a Mac-Plus with Finder 5.5. The behavior on the Mac-Plus occurs when I run either my program or the MiniEdit program that comes with LightSpeed Pascal. (leading me to believe that it's not entirely something my program is doing.) MiniEdit on the 128K Mac seems to act okay, but I haven't tested it very thoroughly. Symptoms, Mac-Plus: Suppose I had two lines in the TextEdit window: This is a test. This is another test. Suppose I select all the text (including the space) after the second "This". When I cut it, the display looks like this: (one line) This is a test. s If I cover up the window and show it again (forcing an update) the display looks like this: This is a test.This Assuming I don't move the insertion point (which is at the end of the line), I can do a paste, and everything goes back exactly the way it's supposed to. (Two lines, as when I started.) The selection doesn't have to include an entire line to reveal this problem. It also occurs when more than one line is selected. I think it might only occur when the text to be cut is longer than the rest of the line that it's on. It's almost as if TextEdit loses track of the number of lines it has, so it loses the last member of the "lineStarts" array. (Maybe I'll try doing a TECalText just for grins.) This confusion messes up the display; TE thinks it only has to redraw the character immediately preceding the selection (in case the inverted rectangle overlapped it?), when it actually changed more than that. On a 128K Mac, the above doesn't happen. Instead the problem is with part of the selection rectangle lingering when it should go away. In the example above: This is a test. This is another test. suppose I select everything after the first period, then cut it. The insertion point is left after the first period, as expected, but the inverted rectangle between the new insertion point and the end of the line (the right side of the window) is still there. As soon as I start typing at the insertion point, it goes away. I'm using LightSpeed C for this project. The TextEdit destination rectangle is (4, 4, 32767, 32767). The view rectangle is the window minus the scroll bars. (The top left is (0, 0).) I don't think it's a problem with the Origin being wrong. I doubt it's got anything to do with the current grafPort, since editing and drawing seem to be getting done correctly for the most part, and I don't change it unexpectedly. Perhaps this is a LS bug? (shared with LS-Pascal, since the MiniEdit program showed the same Mac-Plus symptoms?) Perhaps the Mac-Plus symptom is a problem mixing LSC with the new System? Perhaps a TextEdit bug? Any explanations, workarounds, bug-fixes, or words of encouragement are solicited. Thanks. PS: Thanks, Apple, sincerely. 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