This question already has answers here:
UILabel text margin [duplicate]
(38 answers)
Closed 9 years ago.
I'm trying to indent the text in a UILabel to leave some margin around the text showing the background colour. Following the suggestion here I've overriden textRectForBounds:limitedToNumberOfLines: like so:
- (CGRect)textRectForBounds:(CGRect)bounds limitedToNumberOfLines:(NSInteger)numberOfLines
{
CGRect intermediate = CGRectMake(bounds.origin.x+MARGIN,bounds.origin.y+MARGIN,bounds.size.width-2*MARGIN,bounds.size.height-2*MARGIN);
return [super textRectForBounds:intermediate limitedToNumberOfLines:numberOfLines];
}
But no matter what I do, the text ends up tight against the left border of the rectangle. It seems as though the drawing is ignoring the origin part of the returned CGRect (although it seems to be respecting the width part, as if I reduce to width of intermediate to eg bounds.size.width-200 the rect that textRectForBounds returns is suitably narrow and the text is drawn in a long skinny column).
So: what else I need to do to the UILabel to make the drawing respect the textForRectBounds-returned-rect's origin.x and origin.y? I'd rather not override UILabel's drawTextInRect if I can help it.
Update: This was a long time ago and I can't remember exactly why the other question didn't work for me. I believe it was because I was trying to have a UILabel with multiple lines, and the solution here didn't work in that case.
I think you should override both textRectForBounds:limitedToNumberOfLines: and drawTextInRect: like this:
- (CGRect)textRectForBounds:(CGRect)bounds limitedToNumberOfLines:(NSInteger)numberOfLines
{
return CGRectInset(bounds, MARGIN, MARGIN);
}
- (void)drawTextInRect:(CGRect)rect
{
[super drawTextInRect: CGRectInset(self.bounds, MARGIN, MARGIN)];
}
Check the documentation, it might be of some help. calls to super might not be returning the values you assume.
You should not call this method
directly. This method should only be
overridden by subclasses that want to
change the receiver’s bounding
rectangle before performing any other
computations. Use the value in the
numberOfLines parameter to limit the
height of the returned rectangle to
the specified number of lines of text.
For this method to be called, there
must be a prior call to the sizeToFit
or sizeThatFits: method. Note that
labels in UITableViewCell objects are
sized based on the cell dimensions,
and not a requested size
The default implementation of this
method returns the original bounds
rectangle.
Good luck!
Related
I subclass UISlider in order to make the thumb smaller, and I want to override minimumValueImageRectForBounds and maximumValueImageRectForBounds to make their width 2px less. So my code is
- (CGRect)minimumValueImageRectForBounds:(CGRect)bounds
{
CGRect stdRect = [super minimumValueImageRectForBounds:bounds];
return CGRectMake(stdRect.origin.x + 2, stdRect.origin.y, stdRect.size.width - 2, stdRect.size.height);
}
The point is that stdRect is empty rectangle (0, 0, 0, 0).
Morover, if I explicitly set some rectangle like that
- (CGRect)minimumValueImageRectForBounds:(CGRect)bounds
{
return CGRectMake(2, 0, 40, 8);
}
It doesn't affect minimum value image position at all.
Any ideas?
Haha, I just figured it out. I wasn't reading closely enough.
Setting the minimumValueImage is not the same as calling setMinimumTrackImage:forState:. The minimumValueImage is an image that gets displayed to the left of the slider and is independent what's going on in the slider. Overriding minimumValueImageRectForBounds changes the dimensions of this image (the default size being 0pt wide) and the sliders frame is made less wide and shifted to the right as a result. As I understand it, there isn't a way to modify the rectangle of the minimumTrackImage (such as to make it extend to the right of the thumb image); it is only possible to change the image.
I haven't really figured out the point of allowing you to set the minimumValueImage. It seems like you could accomplish the same thing by changing the size of the slider and adding separate UIImageViews to the side of the slider. Who knows.
Note that everything I've said here applies in the same way for the maximumValueImage and setMaximumTrackImage:forState methods.
DO NOT DO THIS. This is an old, incorrect answer, by past me. I hate that guy.
--
As a general rule, you probably don't want to subclass the Apple standard UI controls. You might want to build it up and set those properties yourself instead (not sure if they are settable, but seems like they should be).
Is this possible? Basically, I have a bunch of NSAttributedString objects and corresponding CTLine objects. I want to get the image bounds before the drawRect stage. So at this point, there is nothing to draw into. I will then use these image bounds to decide exactly what I need to create for drawing.
EDIT: Another measurement of the size would probably work just fine. But calling the deceptively named CTLineGetTypographicBounds function only returns the width. If I pass in addresses of ascent and descent floats, they come back as zero.
EDIT: The given answer works great in MacOS. Can anyone do it in iOS?
If you are developing for iOS6+. You can use the following method:
CTLineRef line;
// Create the line...
CGRect bounds = CTLineGetBoundsWithOptions(line, kCTLineBoundsUseGlyphPathBounds);
// use bounds...
This is gives the same bounds as CTLineGetImageBounds() assuming you have no transforms applied in your context, but does not require the context. For iOS 5 and below, you would need to use the method described by Иван.
CTLineGetTypographicBounds() gives me a different width than this function or image bounds. I am not sure why. And the ascent and descent returned are those of the font and not the characters displayed in the CTLineRef.
Yes, you can, but not so easy.
You should, generally use CTLineGetTypographicBounds() which, for me, does return ascent, descent and leading, but a bit messed up - 'ascent' equals the total height (i.e. what should be ascent + descent) and 'descent' is always the maximum descent of the font - no matter if you have descending characters or not.
Other way is to retrieve the CTRun(s) from the line (CTLineGetGlyphRuns), then get the glyphs array (CTRunGetGlyphs or CTRunGetGlyphsPtr) and then using CTFontGetBoundingRectsForGlyphs and CTFontGetAdvancesForGlyphs build up the information you need.
EDIT:
I've just found this method: "- (NSRect) boundingRectWithSize:(NSSize)size options:(NSStringDrawingOptions)options" of NSAttributedString which seems to do exactly what is needed.
Hope, this is helpful...
Bounds returned by CTLineGetTypographicBounds() are not the same as image bounds. As the name, (and Иван's answer) suggests, ascent etc. are defined for the font and won't change based on the string. For example, you would use it if you want to find the correct line height if you have a multiline text, as line height normally should not depend on the exact characters you use.
CTLineGetImageBounds() on the other hand, returns the bounds that exactly fit the image. For example, if you want to draw a box around a single line, this is what you need.
CTLineGetImageBounds() needs a context because there may be text transforms and things like that. If you don't want to worry about that, just use a dummy context. For example:
CTLineRef line;
// create the line...
UIGraphicsBeginImageContext(CGSizeMake(1, 1));
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextSetTextPosition(context, 0, 0);
CGRect bounds = CTLineGetImageBounds(line, context);
UIGraphicsEndImageContext();
// use bounds...
Another method is to convert the string to glyphs usingCTFontGetGlyphsForCharacters() and then calling CTFontGetBoundingRectsForGlyphs() with the glyph array you get from the first function. The latter function returns "the overall bounding rectangle for the glyph run" so don't worry about having to do processing on the individual bounding rects. If used both these functions successfully in iOS.
If you do this remember the mapping between glyphs and characters is not always one to one, especially when the string has non-English characters.
I have created a UITableViewCell using UITableViewCellStyleValue1, which the Apple docs define as:
A style for a cell with a label on the left side of the cell with left-aligned and black text; on the right side is a label that has smaller blue text and is right-aligned. The Settings application uses cells in this style.
I am trying to set the cell text to display some short text on the left, and some long text on the right, e.g.
URL http://www.mylongurl.com/subdirectory/etc
My problem is that the left UILabel gets truncated instead of the right one so it displays as:
U... http://www.mylongurl.com/subdirectory/etc
If I make the URL even longer then BOTH the labels get truncated, e.g.
U... http://www.mylongurl.com...subdirectory/etc
Is there any way to make the right UILabel truncate instead of the left one without using a custom UITableViewCell? I know how to create a custom UITableViewCell, but it seems like overkill?
I can set the UILineBreakMode to change where the text truncates within the UILabel, but I can't see a way to make the detailTextLabel adjust its width to let the textLabel display itself.
[[lCell textLabel] setText:#"URL"];
[[lCell detailTextLabel] setText:#"http://www.mylongurl.com/subdirectory/etc"];
[[lCell detailTextLabel] setLineBreakMode:UILineBreakModeMiddleTruncation];
You have a couple of options.
Probably the closest in spirit to what you seem to be asking for is to muck around with the label frames in your UITableViewDelegate's tableView:willDisplayCell:forRowAtIndexPath:. (Doing cell layout modifications in your UITableViewDataSource's tableView:cellForRowAtIndexPath: won't fly, since UITableViewCells do all their own internal layout work after tableView:cellForRowAtIndexPath:.) You can use NSString's -sizeWithFont: to help figure out the layout requirements for your textLabel.
You can also take different approaches, as you mentioned, such as subclassing UITableViewCell or setting cell.textLabel.adjustsFontSizeToFitWidth = YES.
The best solution would be to create a subclass of UITableView cell and set your customizations to the labels like you have here in init. You will probably want to override layoutSubviews and resize the labels if you want the left one to be wider.
- (void)layoutSubviews {
[super layoutSubviews];
self.textLabel.frame = CGRectMake(0.0, 0.0, 100.0, self.frame.size.height);
self.detailTextLabel.frame = CGRectMake(0.0, 0.0, 220.0, self.frame.size.height);
}
Obviously those are arbitrary values. You will want to play with different sizes to meet your needs.
I have a custom table cell which contains a number of UILabels. At runtime, I am adjusting the height of the labels to fit their contents using sizeWithFont:constrainedToSize:lineBreakMode: and repositioning them accordingly. The last label in the cell contains a large amount of text, causing it to wrap, and I'm having a very odd problem. Although the sizeWithFont call returns the correct size, and I'm setting the UILabel's frame to that height, it draws a couple of lines short. This screenshot illustrates what I'm talking about:
In this example, the height of the full block of text should be 90 (as checked in Interface Builder), and that's what returns from sizeWithFont. It's also the height that the UILabel's frame is set to, which I have verified by logging and also by stopping execution and inspecting the value. However, as you can see, it's clearly not drawing the full 90 pixels high, although it's correctly allocating the space for it (the thin black line above 'Edited' is the table cell border). I'm completely perplexed. If anyone can offer some insight as to why it's behaving this way, I would be very grateful.
At last, a solution!
Turns out that the cell does layout twice -- once during heightForRowAtIndexPath, which is where I tweak all the heights of the subviews and the cell, and later during some untraceable transaction originating in __CFRunLoopDoObservers. How did I trace this? I added a layoutSubviews override to my custom table view cell class so I could breakpoint it.
During the second pass, the last UILabel subview was getting set to a shorter height than I set it to, probably in accordance with some arcane autoresizing rules. (Yes, I tried tweaking all of those settings first, with no success.) As it turns out, merely doing nothing in layoutSubviews disabled this framework behavior, allowing me to completely control how my views draw.
With iOS 8 it doesn't work anymore like this. Implementing layoutSubviews alone doesn't do the trick, because the layout of subviews have already changed when the method is called.
I have found 2 solutions:
adding NSLayoutConstraint to layout the subviews programmatically
implementing subview's layoutSubviews and change the frame
An example für solution 2:
- (void)layoutSubviews
{
[super layoutSubviews];
CGRect frame = self.frame;
frame.size.height = 39.f;
self.frame = frame;
}
I've fought with similar problems. It was to do with other properties being set in previous incarnations of the cell. To find it / prove it I changed the reuseidentifer for the offending cell to make sure it was a unique cell.
Can we resize the width of the row of a UITableView.
What exactly are you trying to accomplish?
I'm not 100%, but I am pretty sure each row is going to be with same width as the parent table. However, if you have a custom UITableViewCell, you can make it transparent, and organize your objects on the cell's view to mimic a different sized cell. For example if you wanted a cell to be 50px less wide than the other cells and indented, you could place a white UIView on the transparent cell, make it 50px less wide than it should be, and position it to the right.
Make sense?
I understand this is an old question, but I need a table cell to be less than the width of the screen, but still be scrollable by touch on either edge, and the cell highlight not to be full width.
I overrode the UITableViewCell setFrame method, like so:
- (void) setFrame:(CGRect)frame {
if (frame.size.width > 540.0f) {
frame.origin.x = (frame.size.width-540.0f)/2.0f;
frame.size.width = 540;
}
[super setFrame:frame];
}
I guess this is a slightly hacky solution, but it works a treat!
Hope this helps someone.
Only if you fit the whole table into a smaller area.