Thanks for the quick response. I think I'm okay with sending stuff through the sender parameter, although I do agree it's a bit ugly.
Problem is, my didSelectRowAtIndexPath isn't getting called... :-( The delegate is set correctly, so I'm assuming iOS doesn't call it in the presence of segues? It IS calling prepareSegue... -- Rick On Apr 2, 2012, at 4:10 , Roland King wrote: > in -didSelectRowAtIndexPath you get the object then you call > performSegue:withIdentifer:sender with the object you just got as the sender. > > in -prepareForSegue you have the destination view controller from the segue > object and you have the 'object' you used as sender, the object from your > table. Set that object into your destination view controller and you are > done. > > Sender is a bit of a bad choice for that parameter I think, you can see why > it's called that because in the case of a normal button type segue it is the > button you pressed so it's a sender, but if you use performSegue:: yourself > you can send anything you like and pick it back up in the prepareForSegue > method. > > I suppose alternatively you could use the master table as your 'sender', get > the indexPathForSelectedRow and use the master table's datasource to look > that up in the prepareForSegue method, but .. why bother, it's so easy the > other way. > > On Apr 2, 2012, at 6:57 PM, Rick Mann wrote: > >> I have a simple storyboard app with a push segue from a master table to a >> detail controller. In the past, I'd implement -didSelectRowAtIndexPath, get >> the object for that row, create the detail view controller, assign the >> object to it, and push it. >> >> Now I don't really see a nice way to do that without an ivar in the master >> view controller. I can either override prepareForSegue, in which case I >> won't have the index path available, or call performSegue, in which case I >> won't have the destination view controller available. >> >> Am I missing something, or must I store the object in an ivar in one, and >> get at it in the other? >> >> TIA, >> Rick >> >> >> _______________________________________________ >> >> 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/rols%40rols.org >> >> This email sent to r...@rols.org > _______________________________________________ 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
