Thanks for this, I did something like this a long while back and must have confused the “Display” path with the “Layout” path, thanks for putting me on the right track again. The its written it will be very easy to change what I have already to do it the way you describe below.
Honestly, that means using autolayout because that “is thew way Cocoa works these days” but I sympathize with a strong desire to avoid it, as well as there being a number of use cases it simply can’t handle.
The amount of time it was taking to make the board for the game I am working on to work was ridiculous for the return. The number of constraints was enormous and it was really slow when resizing. Add to this that as soon as you wanted to change something it sometimes meant re-doing *lots* of constraints and still it wasn’t 100%. It’s not Auto-Layout itself, the underlying technology is really good and I’d love to use it, but the tools we have for creating the Layouts in the first place are just horrible and unforgiving. I think a lot of it is due to having everything shoved into one giant all-purpose window/tab in Interface Builder. IMO its needs a specialist window that is designed specifically for Auto-Layout generation.
Where you put resize logic probably best depends on who knows the most about how views should be laid out. For a super view that auto resizes subviews, its -resizeSubviewsWithOldSize: method is called anytime its frame changes. That is a better place to perform resizing on subviews, since it will be called by any method that changes the view's frame. If you want each subview to manage itself, you would override -resizeWithOldSuperviewSize: in the view. IMHO, it makes more sense for the superviews to manage their subviews so you avoid a bunch of subclasses that do nothing but self-resizing.I’m in two minds on this, a lot of the work can be done in a View Base Class that the subviews inherit from, this means that each subview has minimum extra code, but you can override it if you want to. I’m actually working on a number of games that use (mostly) a common board, each Game-App, and I can pull in Custom Views for the Games if I like, just by either adding or replacing a View in the Hierarchy and can be done in IB with no or minimal code changes.
Thanks again for your help.
All the Best
On 22 Sep 2018, at 16:54, Keary Suska <cocoa-dev@...> wrote:On Sep 22, 2018, at 5:29 AM, Dave <dave@...> wrote:This is incorrect: “layout” methods were added when autolayout was introduced in Lion (10.7). Before that, you used “frame” and “display” methods, and it was generally the responsibility of the superview to resize its subviews when its frame changes.