Thanks a lot for responding.
Thanks for the post, it’s hard not seeing the code and how you're setting constrains in code. Would you be so kind to provide your code where you setting the constraints so developers here can see it? [..] it is generally not a good idea (and will lead to crashes) to directly modify the frame or bounds of a view that is managed by Auto Layout in my opinion.
Initially I did not involve Autolayout at all explicitly. What I had was a small container view controller with something like this (no explicit constraints):
@implementation SmallInfoWrapperViewController
-(void)viewDidLayout
{
[super viewDidLayout];
NSRect bounds = self.view.bounds;
CGFloat lineHeight = 1.0;
self.separator.frame = NSMakeRect(0.0,bounds.size.height-lineHeight,bounds.size.width,lineHeight);
BOOL separatorVisible = !self.separator.isHidden;
CGFloat wrappedViewHeight = bounds.size.height;
if (separatorVisible) { wrappedViewHeight -= lineHeight; }
self.wrappedView.frame = NSMakeRect(0.0,0.0,bounds.size.width, wrappedViewHeight);
}
@end
That was fine when wrappedView was an NSScrollView (which contains an NSOutlineView).
The NSScrollView/OutlineView/Clipview triplet comes out of a xib which is many years old that also has no explicit Autolayout constraints. All worked fine. Once wrappedView became an NSGlassEffectView (which now contains the scroll view) that is when Autolayout said it needed to break constraints the system was creating from autoresizing masks and it listed weird fixed width and height constraints.
I find Autolayout useful but avoided it in certain situations where it seems unnecessary it could overcomplicate and the task was so easy (like this one) it felt like cutting a stick of butter with a chainsaw. But the system seems to be trying to make Autolayout somewhat of a requirement so rather than try to fight it I just gave in.
self.wrappedView.translatesAutoresizingMaskIntoConstraints = NO;
[NSLayoutConstraint activateConstraints:@[leading,
trailing,
bottom,
top]];
But I initially forgot to remove self.wrappedView.frame from -viewDidLayout which is when I hit the exception. Fix is to instead modify the constant of the top constraint when separator.isHidden changes instead. So I already knew what caused the issue and how to fix it but the exception: "The window has been marked as needing another Layout Window pass, but it has already had more Layout Window passes than there are views in the window" did make me curious enough to ask this question because it doesn't seem so uncommon/unreasonable to make adjustments in -layout and -viewDidLayout. Something like:
-(void)layout
{
[super layout];
[self.dateLabel sizeToFit];
if (![self doesDateLabelFitAtNaturalWidth])
{
[self useShorterDateStyleLayout];
}
}
Of course the above is just "concept code" but shrinking a control based on available space in certain situations is more straightforward and easier to maintain in manual layout than with Autolayout. Most of the time Autolayout is preferred, I agree.
In any case it doesn't feel appropriate for the system to generate width and height constraints from autoresizing masks ever (perhaps I have a naive point of view but that looks like it could cause some real trouble to me). IMO it makes sense to generate leading, trailing, top and bottom constraints but width/height I'm not sure about that. There was like some weird 250 point min width constraint or something and I have no idea how that possibly could have been calculated from autoresizing masks. In another area I had to fix I also ran into a min width constraint conflict when I downsized a window width because the generated constraint from an autoresizing mask somehow created a weird min width 50 constraint that was too big for the really small window size.
Overall it now seems somewhat dicey to set frames in -viewDidLayout / layout overrides because even if you aren't using constraints explicitly it is difficult to determine what the system is generating under the covers.
What do you mean by legal?
What I mean by legal is safe to modify and supported. In my opinion I think there should be a point (like UIKit -viewDidLayoutSubviews) where layout can be safely modified with or without explicit Autolayout constraints to give developers maximum control (even though rarely needed). I don't really understand why the system doesn't permit a more hands off approach like this:
self.lockLayoutInvalidation = YES;
[self doAutolayoutOnSubTree];
[self callViewDidLayout];
self.lockLayoutInvalidation = NO;
Whatever the layout is after viewDidLayout - it is what it is. Any overlapping views or mistakes or whatever leave it on the developer to find and fix but crashing, throwing, etc. seems a bit much.
Topic:
UI Frameworks
SubTopic:
AppKit
Tags: