On Nov 25, 2013, at 18:48 , Kyle Sluder <k...@ksluder.com> wrote: > Sure, you could, but why? Then your container VC has to reach in to your > table view controller and point its table view at itself. > > Why not just do the sensible thing and make the container VC responsible for > managing the bar and positioning of the table view relative to it, leaving > the management of the table view itself to the child table view controller? > > If you have other objects that need to access the table view controller, it > is not hard to expose it as a public property of your container VC.
So, I have basically one property that needs to be reflected at the top of the table. You're saying it's best to make a whole, separate view controller just to do this? This doesn't seem useful at all, especially since in days of old I could easily make a view controller that controlled a view, and manage a table view as one of the many subviews within that. And, I've done it as I described, by ensuring self.tableView always returned the table view, and self.view returned the containing view. -- Rick
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
