brian@ut-sally.UUCP (Brian H. Powell) (07/07/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-9536brian@ut-sally.UUCP (Brian H. Powell) (07/07/87)
I checked out my program with System 3.2, Finder 5.3. TextEdit doesn't
show the anomalies I mentioned using this older, more robust system software.
I added code to my cut function to cause a TECalText and an InvalRect on
the TextEdit view rectangle to see what would happen. It fixes the problems
on both the 128K Mac with System 2.2 and the Mac-Plus with System 4.1. It's
ugly, though. If I were more enthusiastic, I'd figure out exactly what needs
to be invalidated.stew@endor.UUCP (07/08/87)
Regarding bugs in text deletion using System 4.1, I have a "Special Edition"
TechNote 131, "TextEdit Bugs in System 4.1."
Quoting from page 3:
Text Deletion
Under certain circumstances, if you select a portion of text within a
single line and delete it, the text doesn't get redisplayed properly.
The caret is drawn on the previous line, and it looks like more than
just the selected text has been deleted; any editing action after the
text deletion causes the display to correct itself and the missing
characters to return. We currently have no workaround for this
problem.
Looks like you've hit this bug. Maybe in system 4.2?
Unfortunately, I don't have the whole technote online. I imagine it'll be
out with the batch due out in the next week or so...
Stew Rubenstein
Cambridge Scientific Computing, Inc.
UUCPnet: seismo!harvard!rubenstein CompuServe: 76525,421
Internet: rubenstein@harvard.harvard.edu MCIMail: CSCdgold@apple.UUCP (David Goldsmith) (07/08/87)
In article <8425@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes: > I checked out my program with System 3.2, Finder 5.3. TextEdit doesn't >show the anomalies I mentioned using this older, more robust system software. This is a bug in the new TextEdit which was added in system 4.1. It will be fixed in a future system release. -- David Goldsmith Apple Computer, Inc. AppleLink: GOLDSMITH1 UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold CSNET: dgold@apple.CSNET, dgold%apple@CSNET-RELAY BIX: dgoldvid no