On Sep 26, 2019, at 10:55 , Laurent Daudelin <laur...@nemesys-soft.com> wrote: > > I’m pretty much in the same situation. There seems to be something going on > behind the scene. I also observed that when I started adding constraints, I > would suddenly get many warnings and errors, some alluding to missing “y" > location where I can clearly see one constraint addressing that “y” location.
What you say sounds correct to me: Richard’s description *is* the old behavior, just with a slightly different UI. The root view cannot be constrained via auto-layout relative to its ancestor, because by definition it occupies the entire geometry defined by its view or window controller. I assume it’s set to “Translates autoresizing mask into constraints” to *prevent* you from adding constraints, not because its autoresizing mask is *actually* translated into constraints (although I guess it may be so, as some internal implementation detail). Subviews, in the past, had the automatic behavior (except for special cases like views inside scroll views). If you didn’t add any constraints, the IB inspector showed the autoresize mask UI with the springs and struts behaviors. As soon as you added any auto-layout constraints, that went away and the frame was completely controlled by auto-layout. The problem with multiple warning and errors when you start adding constraints has been around for a while. Xcode is just bad at knowing when the view is properly constrained, although I’m prepared to concede that there are cases where it correctly complaining, even though the constraints *look* complete to our meager human brains. On top of that, Xcode is really lousy at diagnosing real layout issues at the right level of the view hierarchy. It (pre-Xcode 11, I haven’t played with the new version yet) would be unable to confirm that a view was properly constrained if a subview wasn’t properly constrained, but would complain about the parent view, not the subview. On top of *that*, Xcode was incredibly bad at adding missing constraints. It would often add constraints that didn’t actually fix the problem, leading to other errors, or fail to add the constraints it said was going to add. But there’s more! Xcode would *also* fail to re-evaluate constraints properly *even after you or it fixed the problems by adding the right constraints*. The error messages would often continue to be displayed, but if you quit Xcode and started it again with the same project open, the errors would no longer be there. (!) As I said, I haven’t had a chance to find out whether Xcode 11 is any better at all of this. The only advice I can give is to be persistent, to be thorough, and to think outside the box (literally). _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
