I've seen a lot of NSTextView glitches in Tiger on various apps,
including Apple-provided ones. (I've seen some really nasty things
occur in Mail, as well, but I think Mail might be subclassing
NSTextView.)
I suspect they have some bugs that need ironing out. Come up with a
test case and file radars to get the priority bumped up.
On Jun 25, 2005, at 5:30 AM, Gerriet M. Denkmann wrote:
> My textView (subclass of NSTextView) is visible in a scroll view at
> y = 880 + 700 [textView visibleRect].
> usedRectForTextContainer.size.height = 2000 [layoutManager
> usedRectForTextContainer: textContainer]
>
> Then I delete programatically 20 lines = 280 points somewhere at
> the top of my text.
>
> Then I do: [textView scrollPoint: NSMakePoint(0,
> visibleRect.origin.y - 280) ]
>
> (This has the effect that the bottom lines appear not to have moved
> in my window, although something was deleted at the top of the text).
>
> In Panther I get just what I want.
>
> In Tiger (10.4.1) the last visibleRect.size.height - 280 points at
> the bottom of the page are a copy of the top of the page before I
> did my deletion.
> This looks confusing and extremely silly.
> These bad area goes away when I scroll it out of the window and
> back again.
>
> Or I can do a [textView setNeedsDisplay: YES ] immediately after
> scrollPoint:.
>
> Is this Tiger behaviour correct? Was it just luck that Panther used
> to do what I wanted?
>
>
> Kind regards,
>
> Gerriet.
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<Cocoa-dev...>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/jstiles%
> 40blizzard.com
>
> This email sent to <jstiles...>
>
