On 2010 Nov 04, at 08:31, Keary Suska wrote: > You have to do all the resizing yourself via code, and watch out for > overlapping view gotchas.
Indeed. For example, if the size is increasing, you'll want to resize first, then draw. But if the size is decreasing, you'll want to draw first, then resize. Otherwise subviews will be clipped during animation and/or permanently misplaced. I've designed a window which has 6 tabs, resizes both height and width, and several tabs have sub-tabs, and some tab views' sizes depends on the content. It took many, many hours to get it all working, and much of the knowledge and code ended up being ad hoc; not abstractable for re-use. And there still may be a bug or two that I haven't exercised yet. On 2010 Nov 04, at 08:27, Kyle Sluder wrote: > Incidentally, this is one reason why I don't like the tabless tab view > approach. I'd rather just swap NSViews in the view hierarchy. Certainly worth considering! _______________________________________________ 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
