The problem I've had to continuously hack around is that
NSTextView, in conjunction with NSLayoutManager, is rather eager to
get the text to re-layout.
Maybe, to disable layout, set the textview's textContainer to nil,
then restore it to enable layout?
That's one idea, though I wouldn't be surprised if other things go
weird as a result.
Personally I'd try to work with the text system in a way it expects.
For example:
when I resize the window and need to adjust the frames of both
scroll views, calling -[NSTextView setFrame:] results in the layout
manager invalidating and ensuring layout for the newly visible
character range.
Why not just turn off text view width/height tracking for the
container during the resize? That should let the layout manager use
the existing layout information (ie: for the stale container size).
The other "state change" you explicitly touch upon is editing the
text. If you bracket all your changes to the text storage with begin/
end editing calls, you shouldn't trigger layout until all your changes
are finished (unless you're also inadvertently triggering layout in
other ways).
Are there any other scenarios where you trigger layout before you're
ready?
~Martin
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
