0

Edit: While my comments have an iOS 5 working example, I am still getting this for other versions. I've now implememted a test to only register and dequeue cells if iOS 5, but it's really puzzling!

still receiving _accessibilityUpdateRemoveControl exceptions, strange nuisance, appears to be something with the edit controls, nothing is retained so nothing needs deallocing, but will try, and post the answer if I find it!

This was working yesterday, and now it's not... I changed nothing!

Edit: Turns out, while reloadData causes the crash, the crash does not occur without my custom tableViewCell... hmmm, something about removing the + sign, but it doesn't happen with deletion!

Actual error is this: [CustomTableViewCell _accessibilityUpdateRemoveControl]: message sent to deallocated instance.

What's funny is, the remove button works. Essentially it removes the item from an array, adds it to another, basically putting it "to another table". No crashing, works fine.

If I remove the line that reloads the data in the table, after the insert button adds it, it also works. Eg: Don't immediately reload the data, close window, come back, everything displays fine. The exact line, so far, that crashes it is in

[theTable reloadData], but that line, for the other table (as I update both) doesn't crash at all. Actually, thanks to that, I'm gonna view the headers for UITableView's functions, and view other answers with that specific line. I just didn't see this, anywhere, after searching for that weird function call.

I'm ensuring my cell is within memory, and even quit dequeuing just to ensure it's working. I'm stumped with this, hopefully will have solution in an hr or less.

Thanks

Stephen J
  • 2,367
  • 2
  • 25
  • 31
  • It seems this has to do with my custom table cell, even though subclassed, not implementing something... as this crasher doesn't happen with the normal ones, hmm, will post when I find – Stephen J Mar 13 '12 at 00:00
  • can't answer myself, so in comments: Just had to set this up: [possibleTable registerNib:[UINib nibWithNibName:@"NameOfTableViewCell" bundle:nil] forCellReuseIdentifier:@"Identifier"]; A web search for reuse custom table xib (or similar) hinted that I should register Nibs, and since it's memory issues, I figured that was probably "apple's way of retaining table objects"... then for examples and where, cred goes to Robotic Cat http://stackoverflow.com/questions/8484708/is-it-faster-to-create-uitableviewcell-programmatically-or-load-one-from-a-nib – Stephen J Mar 13 '12 at 00:18

1 Answers1

0

I stepped through Apple's code, line by line, read the name of every function and noticed this: editControlWasClicked: (id) clicked

is called just before crashing. I combined that with the error message, and the fact I call [table2 reloadData] before this is called, and pieced those pieces together.

The cell is erased (so it moves to the other table), but somehow calls its system callBack "editControlWasClicked" after the table reloads... since it's on the main thread, I'm guessing the table stuff is multi-threaded... how else would it call these in order but do that After the reload??

So to test this, I used the "afterDelay" function, and low and behold, it worked.

You may be asking why I'm using an add edit control in one and subtract in the other... there is a purpose to that.

So, possible solutions: 1) use the afterDelay method of selectors. 2) Write a custom IBAction ('cause it's a xib) or otherwise use custom images and functions to ensure that doesn't get called back.

Note, 2 involves writing an extra delegate so that messages from the cell can reach the view controller.

Basic solution: use iOS 5, use the queuing, otherwise do one of the above solutions or figure out the threading/hooks and find a way to do this without delaying. (I would prefer such if I can find it)

Stephen J
  • 2,367
  • 2
  • 25
  • 31