Closed luketheobscure closed 10 years ago
thanks @luketheobscure , good idea!
@escoz - After I submitted this pull request I had a chance to play with this in my own apps. If the tableView is reloaded in willDeleteElement: the app will crash (since the animation is pending). Do you think implementing a shouldDeleteElement: would be better? That would give the custom controller a chance to implement it's own delete implementation (by returning NO).
I have things working fine with the current implementation, but just thought I would suggest it.
That sounds like a better solution, yes. Can you send a PR?
On Sun, Apr 13, 2014 at 12:12 PM, luketheobscure notifications@github.comwrote:
@escoz https://github.com/escoz - After I submitted this pull request I had a chance to play with this in my own apps. If the tableView is reloaded in willDeleteElement: the app will crash (since the animation is pending). Do you think implementing a shouldDeleteElement: would be better? That would give the custom controller a chance to implement it's own delete implementation (by returning NO).
I have things working fine with the current implementation, but just thought I would suggest it.
Reply to this email directly or view it on GitHubhttps://github.com/escoz/QuickDialog/pull/668#issuecomment-40316524 .
Right now you can swipe to delete if you configure a QSortingSection to allow it, but there's no way for the underlying QuickDialogController to be notified of this event (there's really no way, tried all manner of KVO!).
With this change QuickDialogController will now have a willDeleteElement: method, so data sources can be updated after table cells are deleted.