Has anyone got any idea how to debug this?
Warning once only: Detected a case where constraints ambiguously suggest a height of zero for a tableview cell's content view. We're considering the collapse unintentional and using standard height instead.
The rows have a fixed height as set by
- (CGFloat)tableView:(UITableView *)tableView
heightForRowAtIndexPath:(NSIndexPath *)indexPath{
return 34.0;
}
And all the constraints seem to be happy...
Forcing a return height and estimated height made the warning disappear in my case.
- (CGFloat)tableView:(UITableView *)tableView
estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
return 44;
}
- (CGFloat)tableView:(UITableView *)tableView
heightForRowAtIndexPath:(NSIndexPath *)indexPath {
return 44;
}
Another solution where you don't need the two overrides is simply to use self.tableView.rowHeight = 44; in your loadView or init method.
What can also be done is adding vertical constraints from the top and to the bottom of the content view. This will make autolayout happy (because he now knows how to calculate the height of the cell himself).
If you're using autoLayout constraints and UITableViewAutomaticDimension, this error is not some erroneous problem to be discarded by overriding your height in code. It means that determining the cell height automatically isn't working because you don't have the proper vertical constraints needed.
If you're like me and were getting this error and needed help identifying which cell was throwing the error, you can add the following line right before the return of your 'heightforRowAtIndexPath' method.
NSLog(#"Section %ld Row %ld", (long)[indexPath section], (long)[indexPath row]);
This will print out a long list of sections and rows, but the error will appear immediately following the particular cell that is causing the error, and you can quickly identify which cell is causing the problem and fix your constraints accordingly. This is particularly helpful for static cells. Overriding the height with a manually entered number will work if you're not using autoLayout and automatic cell heights, but will essentially disable these features which is a very poor solution if its something you're trying to utilize.
If you weren't previously using the 'heightForRowAtIndexPath' method but want to debug this error without undoing your UITableViewAutomaticDimension setting, simply add this to your code:
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
NSLog(#"Section %ld Row %ld", (long)[indexPath section], (long)[indexPath row]);
return UITableViewAutomaticDimension;
}
There appears to be a bug in XCode 6.1 that causes this problem if using auto-layout and you don't specify a value for the Row Height for each Table View Cell, but instead you leave the "default" value. Simply checking the "Custom" checkbox next to the Row Height, for every cell, makes the warning go away.
Yes, You get all constrains "happy" even in case when you only have horizontal constrains for items in table view cell. I had same issue. You need to add also vertical constrains. Doing so, that warning will go away.
The constraints can be happy for the purpose of layout, but not happy for the purpose of automatic row height. A happy layout would mean the content can be laid out without ambiguity. That would satisfy the checks in Interface Builder.
A happy layout for automatic row height would mean that, in addition to the above, you're also including constraints to the bottom of the cell.
More here: Detected a case where constraints ambiguously suggest a height of zero
I used Row Height 43 (or <> 44) in the Table View size inspector and the error disappeared. Using 44 I get the error. Xcode version 6.0.1.
--
This answer was removed by a moderator, please don't, it fixes the problem. This SOLVES the problem for me and may do it for others too. So could you be so kind not to delete it again.
I couldn't get to remove the warning, but to make constraints work I set the ,new to iOS8 , tableview property estimatedRowHeight to the fixed height, and removed heightForRowAtIndexPath implementation.
If you're getting that warning, it's most likely because you're using auto layout and your cells don't have any constraints inside them.
You should either stop using auto layout or implement constraints that unambiguously define the height of the cells.
You can turn auto layout off in interface builder by unchecking the "Use Autolayout" option in the file inspector on the right.
If you choose to use auto layout and the height of your cells is fixed, implementing the appropriate constraints should be easy. Simply add height constraints for subviews of the cell's content view, and implement vertical space constraints between the subviews, and between the subviews and the content view. For example if your cell has one label in it, this would work:
Vertical constraints
Vertical space constraint between the top of the content view and the top of the label
Fixed height constraint of label
Vertical space constraint between the bottom of the label and the bottom of the content view
Horizontal constraints
Horizontal space constraint between the leading edge of the content view and the leading edge of the label
Fixed width constraint of label
Horizontal space constraint between the trailing edge of the label and the trailing edge of the content view
You can use AutoLayout to calculate the right height for you. Here is a nice post about Dynamic Cell Height on iOS 8: http://natashatherobot.com/ios-8-self-sizing-table-view-cells-with-dynamic-type/
In Swift forcing a return height fixed my problem:
override func tableView(tableView: UITableView, heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
if(indexPath.row == 0){
return CGFloat(131.0)
}else if(indexPath.row == 8){
return CGFloat(97.0)
}else{
return CGFloat(44.0)
}
}
For a bog standard fix, no constraints, no estimating heights, or over engineering the problem. I created a default project, wired up the tableview but forgot to put the height delegate in the view controller. To simply make this warning go away you need this.
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{
return 44;
}
In your table's view controller.
I was using a mapView inside uitableviewcell. I changed the height of map view to 1/3th of the device screen size. I got the same error. I fixed the error by adding missing constraints to the content view of the uitableviewcell.
1) Clear the contentView constraints.
2) Set Reset to Suggested constants to contentView.
3) Add missing constraints - if any
4) We make sure the content view has all the required constraints.
In my case, it is because I'm designing the cell with xib, and I forget to add that xib file to the target.
After I add that xib file to the target, the problem is gone
While the answers on this page discussing adding height constraints or manually returning rowHeights like 44 in heightForRowAtIndexPath cause the warning to go away, they are superfluous because this is a bug in Xcode visible in at least Version 6.3.2 (6D2105).
If you set a breakpoint in viewDidLoad, you'll see that self.tableView.rowHeight = -1 (UITableViewAutomaticDimension) even if you specify a row height of 44 in the storyboard. This is because Apple incorrectly assumes that you want dynamic row heights if you leave the row height at 44, because they didn't provide a flag for you to specify your preference.
Here are some possible solutions and their results:
Set row height to 43 or 45 in storyboard (works).
Manually return a height of 44 in heightForRowAtIndexPath (works).
Add height constraints between the UITableViewCell’s elements and its contentView (works).
Unfortunately, these solutions either require you to change your design, add unnecessary constraints or add unnecessary code to work around a bug. I tried (what I thought to be) the simplest solution:
Set each UITableViewCell’s height to 44 (Custom) in the storyboard (fails).
I really wanted a pure storyboard solution to this, so finally I tried:
Add a user-defined runtime attribute to the UITableView in the storyboard, and name the UITableView with a note about how its rowHeight is being set so future developers can find it: (works):

These bugs are all too common in iOS development and force developers to spend excessive time weighing the ramifications of how their solutions will affect maintainability in the long run.
Since finding a conceptually correct solution that is maintainable and doesn’t seem obfuscated is so elusive, and assuming that Apple will fix the bug and that 44 is going to be the default row height for the foreseeable future, then the constraint or user-defined runtime attribute solutions are probably the most maintainable.
There are two important things happening here, I think.
1) It's super easy to make the constraints wrong if you're ctrl+dragging. So, double check that you have it done correctly. Best to use the tray on the left side of the screen to draw these constraints.
2) Instead of specifying the estimatedRowHeight in ViewDidLoad or somewhere else, use the delegate method
override func tableView(tableView: UITableView, estimatedHeightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {}
This fixed the problem right away for me.
I've also seen this error when using universal storyboards or xibs. If you neglect to specify proper constraints for the Any x Any size class, I've seen this error appear.
Apple seems to have fixed this for iOS9. The error only happened on 8.4 for me.
I went round and round for days between this error and another error in which constraints were being created (no idea where) that conflicted with the constraints I wanted. I even had it working in one instance where every visible property was identical to the other. The only solution I found was to go atomic - create an entirely new file with xib and start again reconnecting outlets copy-pasting the old code. It might not be the best solution, but sometimes, if the problem is not visible, there is little else to do. At very least, going atomic is a good way to review what is going on.
Related
I've an NSTableView with several NSTableColumn objects that appear to have all the correct auto-resizing flags set. However, every time I rebuild the table's contents, the columns all return to a narrow size -- unless I click and manually resize the window.
The NSTableView is inside:
NSWindow
NSView
NSScrollView
NSTableView
(other NSTableView objects: NSTableColumn, NSTextFieldCell, NSScroller (x 2)
Column resizing mask is always:
NSTableColumnAutoresizingMask
NSTableColumnUserResizingMask
The table is created always set with:
[theNSTableView setColumnAutoresizingStyle:NSTableViewUniformColumnAutoresizingStyle];
After reloading the table with data,
[theNSTableView reloadData];
[theNSTableView tile];
...and even:
[theNSTableView setNeedsDisplay:YES];
All views are set to "autoresizesSubviews".
Neither the NSView nor the NSScrollView have any referencing outlets -- could that be the problem?
After discussing this issue at length with Apple Developer Technical Support, they believe there may be an issue with Carbon-Cocoa integration.
However, they also point out that I really should not set NSTableViewUniformColumnAutoresizingStyle and I should be calculating the widths of all my columns in my own code, and then either telling the column to remember its width, or storing the width and making sure to set the same width on each column AFTER I programmatically create the column.
While I can accept this, I had been at least hoping I could programmatically invoke the same method that is called when a user double-clicks on a column divider and the column resizes itself to fit all of its cell text contents. However, DTS tells me those functions are not available.
I have come across other solutions to this issue here on SO and I will see if they can be adapted to create an optimal solution.
This is the first time I use UICollectionView and it is quite interesting, but I hit the following problem. Can anyone help me clarify what is happening ?
With the following code:
- (CGSize)collectionView:(UICollectionView *)collectionView
layout:(UICollectionViewLayout*)collectionViewLayout
sizeForItemAtIndexPath:(NSIndexPath *)indexPath
{
return CGSizeMake(280.0,36.0);
}
I have this display:
Obviously I need a higher space to display the cell reading "Nous sommes" because it has a second line now invisible.
Since this is the fifth line I use the following code (expecting to solve the problem):
- (CGSize)collectionView:(UICollectionView *)collectionView
layout:(UICollectionViewLayout*)collectionViewLayout
sizeForItemAtIndexPath:(NSIndexPath *)indexPath
{
return CGSizeMake(280.0,indexPath.row!=4?36.0:72.0);
}
But here is the result:
Returning a size with a larger height causes the cell to extent horizontally (which I do not want) while still giving the space (vertically) without using it.
I am missing something. Please explain if you can.
I assume the blue rectangle is a subview of the cell (because it is less than your cell width of 280 in the first example). The problem is likely that you need to set your struts & springs (or constraints if you're using Auto Layout) such that your subviews resize the way you want when the cell gets resized. Looking at your layout, I think you want to specify fixed width and flexible height (or the Auto Layout equivalent).
If you're still stuck, please post details about your struts & springs (or Auto Layout constraints).
I can't figure out why when I run my program and press the (+) button for the default predicate control to add another row that it will not increase the size of the predicate control and push the corresponding NSOutlineView below down.
Right now what happens is it will add the rows, but I have to use the mouse wheel to scroll within the small frame, instead of the frame growing to adjust to the height of the rows.
I'm using AutoLayout, not sure if that is a problem in this case. I believe my constraints are set correctly. I put a constraint to ensure that the distance between the NSOutlineView and NSPredicateView would always be -1 so as the window scrolls it stays in place correctly. I am not sure this is even the issue but doubt it at the moment. Just letting you know I'm aware of it.
I FINALLY figured out the answer! Hurray!
Here is the simple answer: SetFrame DOES NOT WORK with AUTOLAYOUT!
Instead you have to edit the constraints!
This means set a constraint for 'height' on the NSPredicateEditor and IBOutlet it to your code.
Then use the following command.
NSInteger newRowCount = [_predicateEditor numberOfRows];
NSInteger rowHeight = [_predicateEditor rowHeight];
[[_predicateEditorHeight animator] setConstant:rowHeight*newRowCount];
Works like a charm!
I'm trying to make a rotation on a tableview to tilt the table (to give the effect of a 3d text crawl similar to the star wars opening crawl).
After looking around I found this question objective-с CALayer UIView real rotation
and the accepted answer seems to do what I want, however when I apply the code to my TableView it does nothing and the table appears as usual.
This is the code I am copying:
float distance = 50;
CATransform3D basicTrans = CATransform3DIdentity;
basicTrans.m34 = 1.0 / -distance;
_tableView.layer.transform = CATransform3DRotate(basicTrans, M_PI_4, 1.0f, 0.0f, 0.0f);
I'm placing this in my viewDidLoad method after creating my array of Strings (that populate the tableView)
I currently only have three other methods in the Controller:
didReceiveMemoryWarning (automatically addd when project created)
tableView: numberOfRowsInSelection (used for setting up the table view)
tableView: cellForRowAtIndexPath (used for setting up the table view and setting the cells text form the array)
My understanding is that the tableview has a CALayer, and that the CATransform3D manipulates this to give the representation of the view in a 3d space. If my understanding is correct then I don't get why the list is shown normally on screen? I appreciate the numbers my not give the effect I want yet but they should at lest effect the appearance of the tableView on screen.
Also I have imported QuartzCore etc and added it in linked frameworks
Solution is to use the code marked as OLD answer in the the - (UITableViewCell *)tableView: cellForRowAtIndexPath: method after the cell is checked for being null.
Since the approach suggested below has not worked, another thing I would try out is applying the transform to the UITableView's subviews. Actually, UITableView is a UIScrollView, so it is just a container for subviews that make up the real content of the table view. I would try something like this:
for (UIView* subview in tableView.subviews) {
subview.layer.transform = ...;
}
I have never inspected a table view subviews hierarchy, so I cannot say whether this will work or you should rather apply the transform to just one of the subviews, but I hope this can lead you in the right direction.
OLD ANSWER:
You could try setting your table view's layer sublayerTransform instead of `transform':
You typically use this property to add perspective and other viewing effects to embedded layers. You add perspective by setting the sublayer transform to the desired projection matrix. The default value of this property is the identity transform.
(source).
I am suggesting this based on the hypothesis that a UITableView has quite a complex structure in terms of subviews, so transforming just the view's layer might have no effect. I haven't tried it, though, so I cannot guarantee it will work.
hi i am working with NSTableView in my app.
I want to display grid lines depending on the number of rows but it shows many lines even when the number of rows are very less.
Is this a usual behavior?
Or am i doing something wrong?
I have checked the horizontal grid lines option from xib.
cannot understand how to achieve this using code.
What I found to work best for me so far is the following code.
Just fool the original grid drawing code to draw only on populated rows.
Subclass NSTableView, if needed and override drawGridInClipRect:(NSRect)clipRect as following:
- (void)drawGridInClipRect:(NSRect)clipRect
{
NSRect lastRowRect = [self rectOfRow:[self numberOfRows]-1];
NSRect myClipRect = NSMakeRect(0, 0, lastRowRect.size.width, NSMaxY(lastRowRect));
NSRect finalClipRect = NSIntersectionRect(clipRect, myClipRect);
[super drawGridInClipRect:finalClipRect];
}
If I understood your issue I may say: "YES". It's expected from the NSTableView to be fulfilled of stripes even when empty if you set it so.
I realize that you want also to manage those lines programmatically. Consider check out this method setGridStyleMask: on the NSTableView Class Reference.
Good luck.