I have a TableView and I specify the height for each cell using the delegate method tableView:heightForRowAtIndexPath:.
When I rotate the view I get this error that I don't quite understand.
It can't satisfy the constraint below and breaks it to continue.
"<_UIScrollViewAutomaticContentSizeConstraint:0x8e8d040 UITableView:0x9423400.contentHeight{id: 213} == -1568.000000>"
Does anyone know what is happening and why I'm breaking this constraint?
UPDATE: This issue is no longer relevant in iOS 8, which adds support for self-sizing cells. It is still relevant for iOS 7 however.
Original answer (iOS 7):
Greg's answer definitely worked for me - I needed to debug my tableView:estimatedHeightForRowAtIndexPath: method. I did some debugging and some quick experiments and here are some things I learned:
Don't use UITableViewAutomaticDimension in the estimated row methods. This constant is for the header and footer methods. I guess I wasn't paying enough attention when I read the documentation :) UPDATE: UITableViewAutomaticDimension can now be used for row heights in iOS 8, part of the self-sizing cells functionality.
Estimating row height of 1.0 results in an exception: "NSInternalInconsistencyException', reason: 'table view row height must not be negative...'" Estimating less than 1.0 has strange results as well.
Estimating between 2.0 and the actual works just fine without any exceptions (although 2.0 is probably a bad choice for optimization reasons - you want to be as close to actual as possible).
The constraint exception only occurs when the estimated row height is greater than the actual row height. The closer you are to the actual, the less likely the exception will occur. How far off your estimate can be before getting the exception seems to be related to several different factors: actual row height, the position of the row, etc.
tl;dr: Look for actual height values drastically different than what you estimated. Or actual values that are negative or 0.
I just spent a few minutes debugging this constraint exception. I have a UITableView with cells, section headers, and section footers. Each of these had the iOS 7 estimatedHeightFor messages defined, returning a static const value. I removed cells, headers, and footers, one at a time until I determined the issue was coming from the footer (not important if you don't have footers, please read on).
If I eliminated estimatedHeightForFooterInSection:, the exception disappeared. In my heightForFooterInSection:, there is one path in which the height of the footer would be 0. When I restored the estimatedHeight message and eliminated the code path for an actual height of 0, the exception also went away. I replaced 0 with 22 and decreased this value all the way to 12 before the exception reappeared.
Regardless, I need the height of the footer to be 0 (I return nil from viewForFooterInSection: in that case) and I want to be able to estimate the height (I am supporting Dynamic Text). My solution was to account for the code path that would give me a 0 height in estimatedHeightForFooterInSection:. Once I added that, the exception went away.
Try to debug your
(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
implementation. In my case it was returning a negative integer in some rare cases, resulting in the message showing up in my log and messing with the scrolling behavior of my table view.
Related
My table view doesn't want to be displayed without weird gaps between its sections. I pinned a screenshot that visually describes the problem.
Note that these gaps are not represented by some kind of UIView, they are just uncovered pieces of the table.
I tried both view/heightForFooterInSection, it did not give me any results.
Methods view/heightForHeaderInSection are already in use (labels describing sections name, seen on the screenshot. If heightForHeaderInSection is set to 0 or any other value less than 10, labels start to look cut.
However I did find the solution: the method tableView.sectionHeaderTopPadding
works just fine, but is only available from iOS 15, that does not arrange me.
I will be grateful for any help. I just don't want tot believe that Apple didn't provide us with any ways to solve this for iOS older than 15.
I think this is more of a general issue. I would like to use a textfield that gets dynamic data and doesn't stretch more than a given max height. For instance, I have a textfield that, if it gets text that fits in one line, the textfield will be one line height, and i have other elements under it, that will move up with float positioning. Or, if I want a 3 line max height and if the text exceeds that space, then the rest will be trimmed.
I don't want to use java expressions to trim that text, as it is not always accurate. I am new to jasper and I am trying to know if there is any way to do this. I did a lot of searches, but maybe there is something that i missed, and i hope someone can help me. Thank you
I managed to solve this by extending net.sf.jasperreports.engine.fill.TextMeasurer and overriding initialize() method; also I had to extend net.sf.jasperreports.engine.util.AbstractTextMeasurerFactory and override the createMeasurer() method.
Now, whenever I want to have max # of lines, with no overflow, I add a property to that text field (e.g. maxLines) which is being passed to my custom TextMeasurerFactory. I hope this helped you.
We had a similar problem at work with JASPER Reports 4.5, where we had an invoice with a header and a table. We wanted the header to have dynamic height based on the lengths of certain fields (like address, partner name, etc,), but not more than a critical limit, otherwise the header will push the table and thus making a mess by splitting it across multiple pages. Also, the invoice shouldn't exceed 1 page.
We eventually had to move the header in the background section, where we also put a background for the table consisting of vertical lines (so it will extend to the end of an A4 page) and a white opaque square.
This way, if the header exceeds the max height it will go underneath the table's background, cropping the text. This was the desired effect we were looking for.
Sounds crazy, but it worked ...
I just inherited code which hides/shows rows a UITableView by using the delegate heightForRowAtIndexPath method and returning height 0 for "hidden rows".
The code works, but it has me concerned there might be fraught with unforeseen complications. Can someone either ease my concerns or give me good reasons why this could cause problems (I couldn't find any issues with initial testing).
The table is fairly small <10 rows total and would require custom row heights even without this hidden row solution.
I do the same thing in the code I just worked on. I am not happy with different behaviour for different table view settings.
The alternative in my case is more complex (a model that adapts to what is visible or not).
For now, I put a //HACK comment on it and document a few peculiarities.
This is what I have found (iOS 5.0 tested):
Set tableView.rowHeight = 1; Zero will give a cell with zero height (as returned by tableView:tableView heightForRowAtIndexPath:) some default height.
You must have a cell separator. If none is selected, then a default height is assigned to zero height rows. The height of 1 is included with the separator.
If your code works in a different way, it would be interesting to know how it is set up.
It would be cleaner to add and remove the rows between two beginUpdates and endUpdates calls, but I don't see why this 0-height method should not work.
If there are no UI-artifacts, that is (e.g. the Delete button showing up overflowing to the next cell).
I use this method of setting hidden cell heights to 0. It works well and also means I can animate the inclusion of new cells by expanding the cell height (such as adding a DatePicker Cell like the calendar app does).
A few things I have had to watch out for in iOS 7.1 are that very squashed text does still appear even when a cell height is = 0 so I've needed to remove cell text in that case. Also, I have change the size of the cell's separatorInset as that was appearing as well.
I'm struggling with this problem, although I'm close to the solution, but I guessing I'm missing something.
Here is the situation :
I have UITableView with 30 cells, and one section header (if it's helpful..).
The table size is exactly the size of 3 rows.
The mission : to let the user scroll 3 rows everytime, exactly 3.
I set the pagingEnabled=YES.
What happens is :
"page 1" - 3 rows - ok (rows 0-2)
swiping to "page 2" - next 3 rows - ok (row 3-5)
swiping to "page 3" - and the paging is not good, either skiping row 6 and showing row 7-9
or the page is stopped in the middle of the cell of 6 (also tried to move the scroll to complete cell visibilty with scolling end event, but it skips some of the rows on some pages)
Any ideas how to fix the situation, every page = 3 rows only ,without skipping or showing half of cell ?
I don't mind if the way will be without pagingEnabled=YES.
I arrived at the conclusion this is basic thing I will use in the future , and I think a lot of others will use the solution that other friends will give here.
Thanks.
Never thought of using this property in a Table View.
Since it is a subclass of UIScrollView, try instead to use the UIScrollViewDelegate methods and calculate where to stop.
A good place to start can be in scrollViewWillEndDragging:withVelocity:targetContentOffset:. and return the offset yourself.
P.S.
from the documentation:
This method is not called when the value of the scroll view’s
pagingEnabled property is YES. Your application can change the value
of the targetContentOffset parameter to adjust where the scrollview
finishes its scrolling animation.
I have a UITableView with some empty sections. I'd like the user to be able to move a row into them using the standard edit mode controls. The only way I can do it so far is to have a dummy row in my "empty" sections and try to hide it by using tableView:heightForRowAtIndexPath: to give the dummy row a height of zero. This seems to leave it as a 1-pixel row. I can probably hide this by making a special type of cell that's just filled with [UIColor groupTableViewBackgroundColor], but is there a better way?
This is all in the grouped mode of UITableView.
UPDATE: Looks like moving rows into empty sections is possible without any tricks, but the "sensitivity" is bad enough that you DO need tricks in order to make it usable for general users (who won't be patient enough to slowly hover the row around the empty section until things click).
I found that in iOS 4.3, the dummy row needs to have a height of at least 1 pixel in order to give the desired effect of allowing a row to be moved into that section.
I also found that the dummy row is only needed in the first and last section; any sections in between don't have this problem.
And it looks like in iOS 5.0, no dummy rows or special tricks are needed at all.
While managing the edit, you can monitor if the table view is in Edit Mode. Use that flag inside of cellForRowAtIndexPath to decide weather or not to display the 'blank' row. While in 'regular' mode, the row will not display, but when the user taps 'edit' cellForRowAtIndexPath should get called again and this time decide to display the row. The details of how to do that depend on your data source and how you are gluing it to the display. If you aren't getting the call again, you can manually inject rows with insertRowsAtIndexPaths / deleteRowsAtIndexPaths and/or call reloadData to force a refresh.
I found that if you return -1.0 from the heightForRowAtIndexPath method it will remove the 1 pixel line.