I have a Swift Application that has a table view, where inside each cell is another sublist which we keep in a second table view.
Each table view cell is composed of a Header area, another table view with sub items, and a footer area.
For some reason when you click right below the inner table view (highlighted in the image), it triggers an NSInvalidArgumentException with the following error and a long stack trace that isn't very helpful (I can provide it if someone thinks it will help).
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UITableViewCellAccessibilityElement superview]: unrecognized selector sent to instance 0x7cd5f480'
I've set an exception breakpoint, but the debugger points to the AppDelegate on class initialization and provides no detailed info of where the error could be occurring.
I've experimented commenting out the code where I set the inner table view's delegate and datasource, and when I do so the error stops occurring, so I think that indicates that something is wrong with the inner table view.
The source code for the Custom Cells in question is located here
I'm assuming that the problem has something to do with accessibility, but I honestly have no idea what that even is, and have not been able to find related errors from my google searches. Thanks for the help!
First off,
You should not have a table view inside of another table view. This can cause problems, as you have found. I suggest that you adjust your code to insert cells dynamically and have multiple cell types.
As for your accessibility error, I would try toggling the accessibility checkbox on the storyboard under the Identity Inspector.
If you have any other questions, please let me know.
Related
I have developed a UITableViewController screen. It's working fine on Xcode 10.2 but. When I run on Xcode 11 beta 1 it's crashing like below.
I didn't find what was happening.
In ViewDidLoad
override func viewDidLoad() {
super.viewDidLoad()
tableView.tableFooterView = UIView()
plateNoPrefix.becomeFirstResponder() // static cell textfield in tableViewcell
}
Exception… Attempted to access the table view's visibleCells while they were in the process of being updated, which is not allowed
I have faced the same issue when providing support for iOS 13.
This is a new exception in iOS 13 that UITableView will raise in order
to prevent and proactively alert you of a situation that would
previously cause undefined behaviour and a variety of strange,
seemingly unrelated, and hard-to-debug issues (including crashes).
What is happening here is that UITableView is in the middle of asking
its dataSource to return a cell for each visible row and is
configuring the properties of the returned cells so they can be
displayed. And in the middle of this updating -- most likely inside a
callback from the table view itself about a specific row such as
tableView(_:cellForRowAt:) tableView(_:canEditRowAt:), etc -- your
code is asking the table view to return the visible cells. This is
obviously problematic, because UITableView is right in the middle of
preparing those cells, so it cannot possibly return a meaningful
answer.
The fix for this is to look at where you are calling visibleCells in
the backtrace when this exception is raised, and then do one of two
things:
Option 1:
Move the usage of visibleCells to a better place, so that you aren't
asking for the visibleCells from someplace that is called during the
process of creating/configuring/updating those same cells. A great
place to ask for the visible cells is after the table view lays out,
so for example if the table view is the view of a view controller you
can use viewDidLayoutSubviews(), or in a subclass of UITableView do it
after calling super.layoutSubviews().
Option 2:
Depending on what you're actually trying to do, you might be able to
skip using visible cells altogether. For example, you might be able to
leverage the callbacks tableView(_:willDisplay:forRowAt:) and
tableView(_:didEndDisplaying:forRowAt:) to track when cells are
visible instead.
If you are hitting this exception and you think you are requesting the
visible cells from a location that should be valid/allowed, please
share the backtrace when you hit this exception and details about what
you're trying to do.
Update:
I am sure but plateNoPrefix.becomeFirstResponder() causing the crash. As of now, you can check by pasting this code in viewDidAppear method
OR
Execute this code after delay (Worked for me)
DispatchQueue.main.asyncAfter(deadline: .now()+0.1) {
// Your code
}
For details clerification you can refer Apple Developer Forum
This is a new exception in iOS 13 that UITableView will raise in order to prevent and proactively alert you of a situation that would previously cause undefined behavior and a variety of strange, seemingly unrelated, and hard-to-debug issues
Please have a look at Apple Developer Forum
so I have a problem with UITableView. I have self-sizing cells and one can actually change height as the UITextView inside changes. When I set the UITableViewController editing, I get an index out of bounds crash by the super.
The crash occurs on this line:
super.setEditing(editing, animated: animated)
Error I get is:
Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM objectAtIndexedSubscript:]: index 7 beyond bounds for empty array'
This out of bounds crash is not caused by a line of code that I wrote since I checked every instance where I access an array and none of them are being called when the crash occurs. The exception breakpoint points to the above line too so I am convinced this has something to do with the default UITableViewController implementation of setEditing: animated:.
An interesting point is that this error only occurs when the resizable cell is in the table view. When I create the table view without it, there are no issues. There are also no issues if I keep the cell in but don't touch any of the constraints so that it doesn't change its height. This leads me to believe that somehow a cell that changes height "in real-time" causes this strange crash but since I can't see into UITableViewController implementation to find the line that causes a bug, I don't know how to handle this problem.
Thanks
EDIT
Turns out that a more precise cause for the crash is when a cell tries to change its height as a direct result of a change in editing. So for example, a cell that simply grows or shrinks due to a text view with beginUpdates() and endUpdates() shouldn't cause any problems. But expanding a cell when starting editing is when this issue arises.
I am trying to create a UITableView inside a UICollectionViewCell. My goal is to implement a tableview inside my CollectionViewCell and populate my tableView with simple data. I want to create pages of tableViews populated with different categories of data.
I thought it would be a relative easy task, however I am getting a Threat 1: signal SIGABRT error. The debugger is prints
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason:
'-[TableViewMockUp.ViewController tableView:numberOfRowsInSection:]:
unrecognized selector sent to instance 0x100b07cc0'
I am not sure what this error is telling me. When I look inside my ViewController I don't have a tableView numberOfRowsInSection method.
I have the project on Git if you want to take a look: https://github.com/cyrilivargarcia/TableViewMockUp
Below is a snapshot of my ViewController class
This is a snapshot of my CollectionViewClass which is where I created my TableViews.
Any idea on how I can resolve this problem?
-[TableViewMockUp.ViewController tableView:numberOfRowsInSection:]: unrecognized selector sent to instance 0x100b07cc0
I am not sure what this error is telling me. When I look inside my
ViewController I don't have a tableView numberOfRowsInSection method.
You've hit the nail on the head. The error is telling you "you don't have a numberOfRowsInSection method", and your reply is "I don't have one".
So... you just need to add that method to your view controller :)
Edit: After reviewing your code, to clarify for your specific case...
You had your TableView Delegate and DataSource connected to the wrong thing.
In IB, select your table view...
In the Utilities pane, select the Show Connections Inspector
Click the little "x" to delete the current Delegate and DataSource connections
Drag to the CollectionCell in the Document Outline tree
That should do it!
My app is based on core data using MR.
I have 3 views. The three views are -
a table view where I can select an entity, when tapped it open the second view with all the relatives data and there I have a button that open the third view where the user can modify the data.
My problem is that to open the second view I have to pass from the table the row number to get the exact entity to be displayed, and here everything fine.
But if the selected entity is the last one in the table and the user modify some data that remove the last row(for example if change the category attribute of the entity), when I go back my app crash, because the row number relative that I passed from the first view doesn't exist anymore in my database.
I hope I explained it well. I know the problem, but I don't have any idea of how to solve it.
My problem is that to open the second view I have to pass from the table the row number to get the exact entity to be displayed
You should not pass the index into the table, since you know that it can change.
Alternatively, you can pass the managed object itself, or its objectID (taking into account that objectID is expensive).
In Xcode, in the left pane there's a breakpoint section (the one with the shape of an arrow… more or less). Open that section. If you hit the + button in the bottom left corner of that pane you can add an Exceptions Breakpoint. This will store the your app and highlight the section where it's crashing. From there you might be able to solve your problem fairly easily: you only need to understand why you're still trying to access that row, instead of the new index of the object. If you still need help at that point, please post the section of your code that's crashing and any related code of that class.
I solved my issue by passing the identifier of the entity instead of the row index. So now in the detail view I get my entity using the identifier instead the index.
I've created a table view based on a feed that contains what is essentially a number of form type elements. Simplified think of it as containing two types of elements textboxes and messages. Textbox type cells should contain UITextFields and Message type cells contain a non editable UITextArea.
I have created a custom cell to handle each of the types and render them into a table. So far so good.
The client has requested a prev/next/done inputAccessoryView like the one that safari uses for html forms. A bit of work later I've got that up and running, I add some functionality that makes prev/next skip over message type cells and only call makeFirstResponder when it finds a textbox type cell. Still things seem to be going smoothly.
Then I added, in testing, a really long message to test my row height setting code. When I try to prev or next over this message cell it fails with a:
2012-02-21 11:34:36.642 MobileMarketing[52410:13a03] -[ContactFormTableViewController selectUpdate:]: unrecognized selector sent to instance 0x89802f0
2012-02-21 11:34:36.643 MobileMarketing[52410:13a03] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[ContactFormTableViewController selectUpdate:]: unrecognized selector sent to instance 0x89802f0'
I assume this is because the target field on the far side of the message and now offscreen has been dequeued. I'm reading up on that. But a long way around for a simple question. Does anyone have a good technique for dealing with this problem?
If I'm understanding your problem correctly, you may be able to solve this using scrollToRowAtIndexPath:atScrollPosition:animated as seen here: https://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UITableView_Class/Reference/Reference.html.
If you scroll to the next cell, you can guarantee it exists before you try to makeFirstResponder.