19 replies to this topic

[Matthew Purcell]

Hi All,

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

Thanks,
Matthew

[Tarek]

Thanks a lot Matthew, please always feel free to ask what you want

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!

[Matthew Purcell]

Hi Tarek,

That would be fantastic - around one week would be fine. Thanks again for all your help!

Best wishes,
Matthew

[Panamind]

Tarek,

Can you make that a 1.6.x release?

[Tarek]

Sure, thanks Gary.

[Matthew Purcell]

Hi Tarek,

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

Thanks,
Matthew

[Tarek]

Hi Matthew,

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!

[Matthew Purcell]

Thanks Tarek. You guys are awesome making these changes in response to feedback so quickly - very much appreciated

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)?

Thanks,
Matthew

[Tarek]

You're welcome Matthew

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.

[Matthew Purcell]

Thanks again Tarek. I'll be sure to let you know how it goes

[Matthew Purcell]

Hi Tarek,

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.

Thanks,
Matthew

[Tarek]

Apologies for that Matthew, there was a bug with properly overriding the dispatchRemoveRowAtIndexPathEvent method in the SCArrayOfObjectsSection subclass. I'll send you the fixed update right away, please tell me if you have any more issues.

[Matthew Purcell]

Hi Tarek,

Thanks again for your quick response to this issue. I'll let you know if there are any problems

Thanks again!
Matthew

[Matthew Purcell]

Hi Tarek,

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

Thanks,
Matthew

[Tarek]

Hey Matthew

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!

[Matthew Purcell]

Hi Tarek,

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.

Thanks,
Matthew

[Tarek]

Hi again Matthew,

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.

[Matthew Purcell]

Hi Tarek,

The exact error which I get is on line 1691:

[super commitEditingStyle:editingStyle forCellAtIndexPath:indexPath];

'editingStyle' undeclared

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.

Thanks,
Matthew

[Tarek]

Hi Matthew,

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.

[Matthew Purcell]

Hi Tarek,

Glad to report that all is working Thanks again for sticking with this and helping to get it resolved.

Best wishes,
Matthew