UITableViewCell doesn't currently support autolayout, so no, you won't be able to have the constraints system calculate the height for you.
Luke On Nov 2, 2012, at 10:10 AM, Matt Neuburg <m...@tidbits.com> wrote: > > On Nov 2, 2012, at 9:03 AM, Luke Hiesterman <luket...@apple.com> wrote: > >> Cells are sized according to the value returned from heightForRowAtIndexPath: > > Obviously. And that is why I am calculating (in advance) the value that I > will return from heightForRowAtIndexPath:. I've been doing that for years. > The question is, though, can I now (iOS 6) have the constraints system > somehow calculate that value for me, merely by putting the ultimate values > into the labels of a test cell that isn't in the interface? > > The code I'm using now is at > > <https://github.com/mattneub/Programming-iOS-Book-Examples/blob/master/ch21p622variableHeights/ch21p622variableHeights/RootViewController.m> > > As you can see, I'm hard-coding the numbers in my precalc routine > (viewDidLoad). Basically, I'm *guessing* what the constraints *will* do when > I later give the cell height (using heightForRowAtIndexPath:) and the label > resizes because of the constraints. What I'm saying is, how about if I > perform the precalculation the opposite way, i.e. by resizing the label and > letting it resize the cell? But I can't find a formula to do that. The code > below (in this email) shows the sort of thing I've tried. m. > >> >> On Nov 2, 2012, at 8:07 AM, Matt Neuburg <m...@tidbits.com> wrote: >> >>> Okay, I have this wild and crazy idea. I've got a UITableView with cells >>> that have different heights. The cells' content consists almost entirely of >>> UILabels, and the height of each cell depends on what's going to go into >>> those labels - the cell needs to grow to accommodate the text of the >>> labels. The way I've always done this in the past is to calculate how the >>> labels will be drawn, using NSString sizeWithFont etc, and then lay out the >>> labels and calculate the needed cell size. >>> >>> But it occurs to me that in theory constraints could do all the work for >>> me. I'm already using constraints to resize the actual labels when the cell >>> changes size to assume its final height, but maybe I could use constraints >>> to *make* cell assume its final height based on the content of the labels. >>> The cell is in a nib, so if there were just one label, the code might be >>> something like this: >>> >>> NSArray* objs = [[UINib nibWithNibName:@"Cell" bundle:nil] >>> instantiateWithOwner:nil options:nil]; >>> Cell* cell = objs[0]; >>> cell.bounds = CGRectMake(0,0,320,50); >>> cell.lab.text = // whatever the actual content will be >>> [cell.lab sizeToFit]; // or something :) >>> >>> The idea is that the label will assume its final size and the existing >>> constraints will push the cell height larger as needed. Okay, but it isn't >>> working; the cell isn't growing. >>> >>> My theory is that this probably *can't* work because the auto layout stuff >>> doesn't kick in unless the view is actually in the interface, which (as you >>> can see) it isn't. And probably not until the next run loop, either, which >>> is not good enough; I need to run through a whole lot cells and do this, >>> right now, to calculate all the cell heights in advance of the table >>> appearing. >>> >>> So, am I right that this is just impossible, or is there some cool way to >>> do it that I just haven't stumbled on yet? Thx - m. >>> >>> -- >>> matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ >>> pantes anthropoi tou eidenai oregontai phusei >>> Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do >>> RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html >>> TidBITS, Mac news and reviews since 1990, http://www.tidbits.com >>> >>> >>> _______________________________________________ >>> >>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >>> >>> Please do not post admin requests or moderator comments to the list. >>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>> >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com >>> >>> This email sent to luket...@apple.com >> > > -- > matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ > pantes anthropoi tou eidenai oregontai phusei > Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do > RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html > TidBITS, Mac news and reviews since 1990, http://www.tidbits.com > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
