One should add that you could make the value of a metric a calculation of what's left after other elements are determined. It's a fairly advanced approach that can be tricky. But, it's one way to compensate for font and font size variation.
I would highly recommend Erica Sadun's book on AutoLayout. Either edition. The API is incredibly cross platform mostly and her book is the best treatise on the subject that I have ever seen. It's short and concise and will open your eyes to a lot of the potential with constraints. Sent from my iPhone > On 2015/02/24, at 21:58, Roland King <r...@rols.org> wrote: > > >> On 24 Feb 2015, at 20:06, Aaron Lewis <the.warl0ck.1...@gmail.com> wrote: >> >> Thanks Roland. > > No problem. > >> >> I never know about the contentView and intrinsicContentSize property, >> learned something new today. >> You enlightened me a lot. >> >> So I tried to use interface editor before but got the same result. Now >> I see why. I didn't set a minimal height for the label: > > or change the compression resistance in one of the inspector panels. > >> >> @"V:|-0-[imageView]-0-[label(>=30)]-0-|” > > That’s another way to do it - I think the compression resistance one is > ‘better’ in that if the label font changes, the intrinsic size changes, ie > the amount of vertical space it takes up isn’t just >= 30 (fixed value) but > is >= the minimum size it needs to be able to show all its content. It also > means that if the cell does for some reason get forced down to be really > small, you don’t get an unsatisfiable constraint because with compression the > constraint isn’t required, it’s just highly recommended. > > Something like [ imageView setContentCompressionResistancePriority:700 > ForOrientation:NSLayoutContraintOrientationVertical ] > > or increasing the compression resistance for the label’s vertical compression > should achieve that effect, make the label show but make it only as large as > it needs to be. > > This became more important after iOS7 when the user started to be able to > select font size based on eyesight ability (my iOS font is large) and so > labels can be widely different sizes. > >> Changing the constraints to something like this worked. >> >> >>> On Tue, Feb 24, 2015 at 6:01 PM, Roland King <r...@rols.org> wrote: >>> >>>> On 24 Feb 2015, at 16:44, Aaron Lewis <the.warl0ck.1...@gmail.com> wrote: >>>> >>>> Can someone please take a look at this? >>>> >>>> http://stackoverflow.com/questions/28690947/why-is-this-uiimage-and-uilabel-collapsed >>>> >>>> In short words, the UILabel is invisible when I use a image in the >>>> UIImageView. >>>> It works if I only set backgroundColor. >>>> >>>> I already add a constraint on it .. I couldn't really tell why. >>>> >>>> ― >>> >>> 1) don’t add to the cell, add to the cell’s contentView (see the >>> documentation on UITableViewCell) >>> 2) your vertical layout is ambiguous, almost always the case when something >>> ‘disappears’. The label has an intrinsicContentSize, the image has one too >>> because you have an image set into it. They both have the same default 750 >>> content compression resistance. The cell is a fixed height (unless you’re >>> using auto-height cells in which case this shouldn’t be happening) so one >>> or other of them loses out. In your case the label loses out and its height >>> goes to zero (you could see all this in the debugger by the way). >>> >>> If you drop the content compression resistance in the vertical direction of >>> the uiimage from 750 to 749, or less, then the label should get its height >>> and the image view should get what’s left. >>> >>> And the comment on StackOverflow that you are setting up the views every >>> time you dequeue the cell is accurate. >>> >>> And you could use Interface Builder for this too which is usually easier. >> >> >> >> -- >> Best Regards, >> Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/ >> Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33 > > > _______________________________________________ > > 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/dangerwillrobinsondanger%40gmail.com > > This email sent to dangerwillrobinsondan...@gmail.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
