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 (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

Reply via email to