Re: Triggering UITableView's -didSelectRowAtIndexPath: delegate callback
Re: Triggering UITableView's -didSelectRowAtIndexPath: delegate callback
- Subject: Re: Triggering UITableView's -didSelectRowAtIndexPath: delegate callback
- From: Keary Suska <email@hidden>
- Date: Mon, 29 Feb 2016 10:11:49 -0700
> On Feb 28, 2016, at 11:05 PM, Jens Alfke <email@hidden> wrote:
>
>
>>> On Feb 27, 2016, at 4:27 PM, Keary Suska <email@hidden<mailto:email@hidden>> wrote:
>>>
>>> This results in a much more reliable and extensible decoupling since no other object should know those internal signaling mechanics and should have confidence that any other object interested in the selection will be dutifully notified. In fact, this is how NSTableView works. Why UITableView doesn’t, seems worthy of a radar.
>
> NSTableView doesn’t work that way. Changing the selection programmatically does not trigger a selection-changed notification / delegate callback.
That does appear to be the case, at least almost entirely. I was mis-remembering as curiously, -tableViewSelectionDidChange: is always sent, perhaps simply a side effect to the promise of notifications, but in contrast -tableViewSelectionIsChanging: is not. Looking at my older code I did notice that I needed to work around -selectionShouldChangeInTableView: not being called when I hoped it would.
I stand by my assertion that delegate methods should always be called regardless of whether the triggering event is from the UI or programmatically, and that the fact they don’t has nothing to do with decoupling but instead an implementation decision.
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden