Delete Button in Detail View Controller
Posted 18 October 2010 - 09:31 PM
First off, I have been asking quite a few questions lately but I really do appreciate the excellent support being given.
Hopefully this one will be fairly straight-forward. I have an STV which lists objects within a Core Data entity (all of the table cells are automatically generated). As per usual, a table view cell can be tapped and the detail editing view appears allowing that row to be modified.
For UI consistency and space reasons, there is no room for an Edit button in the main STV for users to tap and see the inline delete buttons to remove rows (objects) from the STV (Core Data entity). Therefore, I have added a Delete button as the tableFooterView on the detail view controller, much like the iPhone Contacts.app. I have got the button wired-up to a selector on the main UITableViewController (i.e. the same class that initialises the STV) but I cannot figure out what code I should write to delete the managed object and then reload the main table view so that the row is removed.
Making things more complicated is that whenever the detail view controller is popped from the navigation controller it appears to do an auto-save, so even with my hackish ways of deleting the managed object, and programatically popping the view off the navigiation controller, there are major problems during the pop and save operation (usually a crash of the app).
Any help would be much appreciated
Posted 19 October 2010 - 06:23 AM
I think what we need to do to solve your problem is expose all the methods that STV uses when the end user interacts with it, and have them accessible directly to you. This way you'll be able to initiate adding and deleting items right from code, just as if the end user has initiated them.
What time frame are you bound with? Is about one week ok with you? Thanks!
Posted 19 October 2010 - 02:27 PM
That would be fantastic - around one week would be fine. Thanks again for all your help!
Posted 26 October 2010 - 11:26 PM
Just wanted to check if you have had any luck with these modifications to STV? It would be awesome as my project is now at the stage where including this functionality would be really good.
Also, could you advise whether this 1.6.x release will also include the custom 1.6.1 that you provided me (which allowed me to show the detail edit view when a user taps the detail disclosure button, and show a different view controller if they tap the cell itself)? There was also that bug which I advised about regarding the need to set allowEditDetailView = YES, call didSelectCellAtIndexPath:indexPath, and then set allowEditDetailView = NO in the accessoryButtonTappedForRowWithIndexPath delegate method to show the detail edit view. It may be worthwhile fixing that little issue before rolling this new functionality into a general release
Posted 27 October 2010 - 03:38 PM
The update is now ready as per our schedule, with all your requests implemented (will send you the update right away). Please note the following:
1- Please replace any call you have to "didTapAddButtonItem" with a call to the newly created method: "dispatchAddNewItemEvent".
2- Please replace any call you have to "didSelectCellAtIndexPath" with a call to the newly created method: "dispatchSelectRowAtIndexPathEvent".
3- To dispatch manual row delete events, please call the newly created method: "dispatchRemoveRowAtIndexPathEvent".
Please tell me if you have any questions. Thanks!
Posted 27 October 2010 - 03:45 PM
Just for clarification, the Delete button which I am implementing is a table view footer within the detail edit view. When the user taps the delete button I then call the new dispatchRemoveRowAtIndexPathEvent method to delete the object currently being edited (as we are in the edit detail view). How would I then go about popping/dismissing that detail edit view, to return to the main STV? The reason I ask is because it seems that STV saves the detail edit view when it is being popped/dismissed so I wanted to make sure that I wasn't calling dispatchRemoveRowAtIndexPathEvent to remove the object and then popping the detail edit view which would re-save the object (or worse, crash the program because the object has been removed)?
Posted 27 October 2010 - 03:54 PM
You should first dismiss your detail view normally, then call the dispatchRemoveRowAtIndexPathEvent method, so it's as if the user just tapped the delete button on the cell itself. Please tell me if you're still having any problems with this.
Posted 27 October 2010 - 04:00 PM
Posted 27 October 2010 - 11:49 PM
The new dispatchRemoveRowAtIndexPathEvent method is working great for programatically removing the row from the STV. However, when I reload the STV later the deleted rows(s) reappear, almost like they are being removed from the STV but the actual Core Data object is not being removed. Do I need to manually remove the Core Data object?
As an aside, all works correctly if I swipe to delete a row in the STV (i.e. the row gets deleted and so does the Core Data object) so it just seems like the programmatic method is not deleting the Core Data object.
Posted 28 October 2010 - 08:41 AM
Posted 28 October 2010 - 01:27 PM
Thanks again for your quick response to this issue. I'll let you know if there are any problems
Posted 28 October 2010 - 08:11 PM
Sorry to be a pain, but with the new version I am getting a compile error. The error is contained within SCTableViewSection.m line 1691:
[super commitEditingStyle:editingStyle forCellAtIndexPath:indexPath];
The error is: editingStyle undeclared
I tried changing the code to the following, which I thought would work:
[super commitEditingStyle:UITableViewCellEditingStyleDelete forCellAtIndexPath:indexPath];
However, that line causes the program to go into an infinite recursive loop resulting in a crash. This seems to be because calling commitEditingStyle:forCellAtIndexPath: just re-calls the calling function again dispatchRemoveRowAtIndexPathEvent: which then calls commitEditingStyle:forCellAtIndexPath: again and so on. I imagine that this recursion is intentional and shouldRemove is not being set to FALSE to prevent the infinite recursion (or I am just misreading the code, which is entirely likely too but nevertheless I am having a few issues here.
If you could provide your expertise again that would be much appreciated
Posted 29 October 2010 - 01:36 AM
Are you sure you replaced all the old files and did a clean build? The line you're referring to should read "[super dispatchRemoveRowAtIndexPathEvent:indexPath];" in the new update.
Please tell me if you're still having issues, thanks!
Posted 29 October 2010 - 04:24 AM
I have done some fairly comprehensive testing and I am getting some strange results, so hopefully this will help us narrow down the problem.
1. If I copy the new Sensible TableView folder (containing all the SC classes) into my own app (replacing the old STV folder), perform a Clean and Clean All Targets, then attempt to compile I get the error as described.
2. If I copy the new Sensible TableView folder into a brand new Xcode project (which has never been compiled) and, without doing anything else except that copy, immediately attempt to compile the project I get the error as described. Performing a Clean and Clean All Targets does not fix the problem.
3. If I run the Samples App it compiles and runs perfectly, even after a Clean and Clean All Targets. However, copying the STV folder from the working Samples App into either my own app or the brand new Xcode project causes the error to occur, even after a Clean and Clean All Targets. This is the weird one as I don't understand why it is working in the Samples App project but not when I copy the exact same files across to my own project.
Could you perhaps do some testing to see whether you can replicate the problem? Probably the easiest is copying the new STV folder from the email attachment that you sent me into a brand new Xcode project to see whether the problem occurs.
Posted 29 October 2010 - 05:12 AM
When you copy the new files into your existing project, what error message do you get? Also, when you open your SCTableViewSection.m, do you find any calls to "[super commitEditingStyle:editingStyle forCellAtIndexPath:indexPath];" ? (the source of your previous compiler error message)
I'll also resend you our latest release just in case.
Posted 29 October 2010 - 03:22 PM
The exact error which I get is on line 1691:
[super commitEditingStyle:editingStyle forCellAtIndexPath:indexPath];
And yes, I do have a reference to that line you quoted as that is the line causing the error. Using the latest 1.6.4 release does not fix the problem. However, strangely enough, the Samples App sample project works fine but when I copy the files into either my own project or a brand-new project the compiler error appears.
I will email you a copy of the brand-new Xcode project which produces the error message.
Posted 29 October 2010 - 05:46 PM
We finally figured out the glitch! It only happens when you compile for Core Data applications, and that's why it wasn't appearing in the initial tests. Will send you the update right away, thank you very much for pointing this out.
Posted 30 October 2010 - 01:30 AM
Glad to report that all is working Thanks again for sticking with this and helping to get it resolved.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users