What's your trigger for the segue? Have you set it up in IB so that a select on the table cell triggers it automagically?
If so then no you have probably lost control of didSelect... So you have two choices. Either do the second thing I said, find the sending tableViewController, get its selected index path in the prepareForSegue: call and then get your object there, or don't bind the segue direct to the tableview, just make a segue (named) between the two view controllers. Nothing will trigger that, only segues starting from user interface elements like buttons trigger theselves. (to do this I usually drag from the UIVC yellow box icon to the second VC). You should then get your didSelect,... call and you can call the performSegue: yourself. There's probably about another 4 ways to skin that particular cat, I've found storyboards and segues to be quite flexible, so flexible sometimes they just fall off! On Apr 2, 2012, at 7:15 PM, Rick Mann wrote: > 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
