> On Feb 28, 2016, at 11:05 PM, Jens Alfke <[email protected]> wrote: > > >>> On Feb 27, 2016, at 4:27 PM, Keary Suska >>> <[email protected]<mailto:[email protected]>> 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 protected]) 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 [email protected]
