Re: Evil setFrame:
Re: Evil setFrame:
- Subject: Re: Evil setFrame:
- From: Kyle Sluder <email@hidden>
- Date: Sat, 07 Sep 2013 22:04:31 -0700
On Sat, Sep 7, 2013, at 09:36 PM, Gerriet M. Denkmann wrote:
> I try to show a nib (which uses autolayout and which contains among other
> things a NewView inside an NSClipView inside an NSScrollView ) like this:
>
> if ( self.neuWindowController == nil )
> {
> // NewWindowController is subclass of NSWindowController
> self.neuWindowController = [ [NewWindowController alloc] initWithWindowNibName: @"SomeNib"
> eventsList: someArray
> ];
> };
>
> [ self.neuWindowController showWindow: nil ];
>
> The last line triggers in my NewView:
>
> -[NewView resizeWithOldSuperviewSize:] NewView 0x101982430 bounds {{0,
> 0}, {437, 252}}
> -[NewView resizeWithOldSuperviewSize:] NewView 0x101982430 frame {{0,
> 0}, {437, 252}}
> -[NewView resizeWithOldSuperviewSize:] NSClipView 0x10197b8e0 bounds {{0,
> 0}, {398, 94}}
> -[NewView resizeWithOldSuperviewSize:] will call super with oldBoundsSize
> {437, 254}
> -[NewView setFrame:] will {{0, 0}, {0, 0}} ← why is super doing this to me ??
> -[NewView resizeWithOldSuperviewSize:] got frame {{0, 0}, {0, 0}}
>
> and from here on nothing works (not too surprising with such a small
> frame).
>
> Something must be terrible wrong in my setup of NewView, but what?
NewView lacks sufficient constraints to specify its size or position, to
it is being resized to zero.
I'm guessing NewView is the direct subview of the clip view? If so, you
_MUST NOT_ change its translatesAutoresizingMaskIntoConstraints
property, and you _MUST NOT_ try to control its size or position with
constraints.
I learned that the hard way over the course of several months. It's
quite a pain in the ass, because a lot of constraints you'll naturally
want to draw will be just as likely to affect the size of the scroll
view's documentView as they are to use the size of the documentView to
affect the subviews.
In our case, we really want to use auto layout to determine the size of
the documentView. But we don't create any constraints between the
documentVIew and any of its subviews. Instead, we add a hidden view as a
subview of the documentVIew, and draw all our constraints relative to
THAT view. Let's call that the adaptor view. The adaptor view has two
constraints that pin its origin to the documentView's origin, but
crucially there are no width or height dependencies between the views.
We then register as observes of the adaptor view's
NSViewFrameDidChangeNotification and update the size of the documentView
to match. The scroll view then dutifully updates its scrollers.
It's unfortunate that we have to jump through all these hoops. Apple
could implement something similar themselves to make working with
constraints inside an NSScrollView much easier—as easy as it is to use
constraints with UIScrollView.
--Kyle Sluder
_______________________________________________
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
| References: | |
| | >Evil setFrame: (From: "Gerriet M. Denkmann" <email@hidden>) |