Re: problems with live resize of NSTextView
Re: problems with live resize of NSTextView
- Subject: Re: problems with live resize of NSTextView
- From: Stuart Malin <email@hidden>
- Date: Sat, 25 Apr 2009 09:48:22 -1000
On Apr 25, 2009, at 9:17 AM, Keary Suska wrote:
On Apr 25, 2009, at 12:05 PM, Stuart Malin wrote:
On Apr 25, 2009, at 5:08 AM, Keary Suska wrote:
On Apr 24, 2009, at 3:06 PM, Stuart Malin wrote:
I have an NSTextView in a custom view, it is set to resize with
the containing view only in the horizontal dimension. When I
resize the window, the text view does resize, and it does re-
layout its content to fit, both on expanding and shrinking.
However, the text view not only changes its frame size height,
but repositions itself (changing the y value of its frame's
origin). Why does it do this?
You need to read the "Cocoa Drawing Guide" and "View Programming
Guide for Cocoa". The answer is explicit: the 0,0 coordinate of
the Cocoa drawing system is the bottom left.
Ah, I wasn't clear, because of course the origin would move down as
the text expands downward. What I am seeing though is that the
origin moves down more than the increase in height, so the text
view isn't just expanding, but expanding and moving downward (that
is, even its top moves down).
Is the NSTextView anchored to both the top and bottom edges? If not,
you may get this behavior.
It had been fixed only to the top. I tried changing to fix to both,
and the behavior remains the same. But this isn't an issue, because in
my situation, the parent view needs to be resized to accommodate the
text view's present size (see comments below).
More important to me: where is the best place for me to detect
this change because I want to change the parent view's height to
accommodate any increase in height in the text view.
One possible approach is to observe
NSViewFrameDidChangeNotification coming from the view. See the
NSView documentation for how to use it.
Thanks for reminding me of this. I need to see whether the
notification occurs before a redraw cycle. If so, I can propagate
relevant resizes up the chain of parent views.
It would probably be better to put the textview in a scrollview (or
make the textview's parent an NSScrollView subclass). You wouldn't,
for instance, want the window to grow larger than the screen size.
The text view's parent is a custom view. There are an ensemble of
these custom views in a parent document view (of a scroll view).
What I am now doing (not yet complete, but I think this path will
work): I've subclassed the text view and have it detect live resizing
changes to its height. When that happens, it posts a notification. The
enclosing view is an observer for those notifications. When the text
view does change size, the parent enclosing view resizes, repositions
the text view appropriately, and posts its own "didResize"
notification so the process can proceed up the hierarchy. I've already
got the text view detecting its live resize height change and posting
the notification. So far, it seems that this is happening before the
draw recycle, which is great, but I need to get a bit further to see
if this is in fact the case.
Thanks for your interest in this, Keary. I appreciate the comments
you've made.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden