UITextField shows its content text bang against the left edge of the field, which is ugly and can be hard to read if the field has a visible border. UITextView, on the other hand, automatically has padding (blank space) around the text. I examined and experimented with all the UITextField properties but I don't see any way they can be used to get padding around the text.
I also tried calling drawText(in:CGRect) on the text field but it had no effect. But I'm not sure what CGRect is needed in that call. I tried different border styles including .none. I also tried making a blank UIView and assigning that to the text field's leftView property but that also had no effect. And I tried doing these things in viewDidLoad, viewDidAppear, and at the point where I'm writing the text into the textField. The text shows in the textField as expected but none of these other things seem to affect the textField's appearance in any way. It seems to me lots of people must show text in a UITextField and somehow get it padded on the left so I'm misunderstanding something but what???
The following works for a field called "textField". It inserts padding by shifting the left side of the field's content 8 pixels right relative to the left edge of the textField:
textField.layer.sublayerTransform = CATransform3DMakeTranslation(8, 0, 0);
This is given in an answer to a different question by user Dhiru (reputation 1285) in Nov. 2016. Thank you Dhiru!
I have to add that I am not familiar with either sublayerTransform or CATransform3DMakeTranslation so I can't be sure that this doesn't have some side effect that isn't immediately obvious. I'm a little worried that it's called "3D transform" whereas there is nothing 3D about my application. But at least for now this seems to answer the question.
Related
I have NSTextField with left, right and top constraints defined (no bottom constraint set). I need NSTextField to grow if content can't fit in it and decrease size if there is unused space left.
Now I have: NSTextField automatically expands with strange behavior if it has multi-line text or too much content, also NSTextField doesn't decrease own's size on window resize.
I haven't found any simple solution written on Swift to solve that problem (I have a lot of such labels with constraints), at iOS everything was working with usual text labels and constraints.
I've created simple project for that question that you can see the problem: [Download Text.zip]
The solutions I've found but not used:
You can try to calculate possible TextField height and set height constraint for it. Problems of that solution:
Possible height calculations are inaccurate, sometimes you calculate incorrect height.
Solutions are written on Objective-C with some complex code.
Run .sizeToFit() on each window resize or text change action. It's not working because .sizeToFit() always compress all text to single line.
Use NSTextView instead of NSTextField. It's good way, but:
I don't need scrolling, editing and other functional of NSTextView. I don't want to call to complex component for simple label.
NSTextView always wants height or bottom constraint, I don't know bottom constraint because content can expand down with new text.
I haven't find full solution to make NSTextView's behavior like I want :)
According to Mac OS X Release Notes (section NSTextField intrinsicContentSize improvements) it’s known bug when height of NSTextField is changed, but width is remained the same. We have two ways to fixing it:
We can specify maximumNumberOfLines to a value that makes sense. That is not good way to us because we don’t know actual number of lines and don’t want to calculate it.
We can set preferredMaxLayoutWidth to a real value. I’ve ended with such code:
Code:
override func viewDidLayout() {
super.viewDidLayout()
textField.preferredMaxLayoutWidth = textField.frame.width
}
In my Xcode 6.2 Swift project I have an issue with Auto-layout (I'm also using size classes) that I'm not able to figure out...
In Main.storyboard I have a view containing, among the others interface elements, a UIButton and a UISegmentedControl that are positioned at the same height on the opposite side of the view.
I'm setting manually all the constraints in Interface Builder (none in code) and my every view is working just fine, except in this case (and this particular issue only occurs when I have a long text).
The button is aligned to the left border of the view and its constraints are:
Leading space to superview == 0
Trailing space to segmented controller >= 8
Top and bottom space to other interface elements == 8
The segmented controller (which has 2 segments) is aligned to the right border of the view and its constraints are:
Trailing space to superview == 0
Leading space to button >= 8
Top and bottom space to other interface elements == 8
The button in the storyboard has a title "Some title", but actually the actual title is always set in code in ViewWillAppear:
myButton.setTitle(aStringThatSometimesIsPrettyLong, forState: .Normal)
The visual result I need to achieve (on every possibile device and orientation) is that the Button title I set in code, while it can be displayed in good length in the interface, should never compromise the size of the segmented control, compressing the labels of the two segments.
So, I want the size of the segmented control to be fixed and I'm willing to accept the fact that the Button title, if long, can be truncated with dots.
Instead, no matter what I try (and I'll explain what I've tried in a moment) when the Button title is very long it is not truncated, instead the segmented control is compressed and therefore its two segments labels are truncated.
So far, I've tried, separately and together, these steps:
Adding a width minimum constraint to the segmented control.
Incremented (in steps, up to 1000) the Content compression resistance of the segmented control while decreasing the correspondent value of the button.
Increased (up to 1000) the Content hugging priority of the button.
I think I can't set a maximum width to the Button, because it can stretch depending on the title set in code and, more important, on what device the app is run on.
My biggest issue is that, no matter what I try, when I run the app I always get the same behavior (button title completely shown, un-truncated, and compressed segmented control). It seems like adding these constraints doesn't change anything, and it never happened to me before with Auto-layout... messing up, a lot, but no change adding constraints, this is new!
Maybe the issue is that the button title is set in ViewWillAppear and not in the Storyboard, but my app wouldn't work properly if I couldn't set its title in code.
Last, but pretty important, I have to admit that, while I've managed so far to get Auto-layout and Size classes working on all devices and orientations for all the (over 10) viewcontrollers of my app, I've actually never written a single line of code for Auto.layout and Size classes: I've done everything in Interface Builder and, if possible, I'd really love to continue this way.
Any suggestion would be really, really appreciated!
Thanks in advance,
Cesare
As #KenThomases pointed out, the constraints I was setting were actually right (actually, it also works with less constraints now that, thanks to his answer, I figured out the issue), but the Segmented control wasn't getting its intrinsicContentSize. Fixed that, now everything's fine.
Ok. I've been at this over and over. I've seen blogs and cocoa dev threads.
I've seen Kyle Sluder's proposed solution, but have yet to find a solution that really works.
How can you position subviews of an NSScrollView with auto layout?
Is it just silently broken ?
Nothing seems to work.
Ok, old question, but this particular issue is a personal bugbear of mine so I'll answer it anyway!
The first thing to note is that an NSScrollView contains an NSClipView, which itself has a view outlet called documentView. These are all added for you when you drag a new scroll view into your storyboard or nib file. By default, the document view is an NSView called simply "View". If you're using a custom view, you can just select this and set its type in the inspector on the right to whatever you want. Otherwise, you'll be adding subviews to it.
The big thing that is easy to miss here is that, by default, the document view has its layout set to 'Translates Mask Into Constraints'. This is fine if the content size will never, ever change, and if that's the case you can simply set the frame of the document view to whatever you want and leave it at that. If you want it to automatically resize itself to fit its content however, there's a few things you'll need to do.
First off, that document view needs to have a completely unambiguous size. If you're using a custom view, I'd recommend giving it an intrinsicContentSize. You should also set 'Intrinsic Size' in IB's inspector to 'Placeholder' and give it a suitable value, or you'll get a bunch of autolayout warnings. If your document view gets its size from its content, all of the subviews must be linked in an unbroken chain from top to bottom, and from left to right, such that the content knows exactly how big it ought to be. This is quite an art in itself, so I won't go into it. A simple example where you have only one subview would be to pin its top, bottom, leading and trailing constraints to its parent, but as noted above if you're doing this, you might as well just set the type of the document view.
Now the fun bit. Select your document view and set its layout to 'Automatic'. Next, add top, bottom, leading and trailing constraints to its superview with a suitable value. I'm using zero, but you might want a small border. Finally, select the TRAILING and BOTTOM constraints you just made and set them to '>=' (greater than or equal) and a priority of 500 or less. The priority is very important, as it has to be less than the priority that the clip view uses to determine its own minimum size. Too high and the clip view will be forced to remain larger than its content, making it impossible in turn for the scroll view to be smaller than its content, rendering it useless.
The technical details aren't important. Just remember to set the document view to layout: automatic, pin all edges, and make the trailing and bottom constraints >= and priority 500.
Note that this will cause your content to hug the top-left corner.
Have you tried setting the document view's setTranslatesAutoresizingMaskIntoConstraints to TRUE?
[_scrollView.documentView setTranslatesAutoresizingMaskIntoConstraints:YES];
I have some static text that is usually only 1 line long that displays in a NSTextField in my xib. In some instances, the text is long enough to warrant 2 lines, and I just want the label to resize vertically to fit it, without giving me scrollers or any thing else. Think of how text on a webpage behaves… that is what I want. I just want the label to grow shrink with different text, and with adjustments to its width. How can I achieve this?
UPDATE
Here is a video of how it currently behaves: http://screencast.com/t/4JYTv7jVG3O
Notice how when the NSTextField is two lines long, there is a big gap underneath the text. This is because the stars and button are aligned at the bottom of the frame, and because I have to have the frame taller to accommodate 2 lines, they stay there. If I can get an answer to this question, I would make the frame shorter for the 1 line text, and make the bottom textfield (with the smaller text) taller to compensate. Can this type of floating layout be done?
One option is to actually use a WebView to display your content. You will then get exactly the behaviour you are expecting, at the cost of a bit of work to manage interaction with the controls.
You would need to set the WebView to display no background, using [webView setDrawsBackground:NO].
You'd also need to construct the content (including the star rating and the button) using HTML/CSS and then use the Objective-C/JavaScript bridge to call back to your app when the button is pressed.
More information on calling Objective-C from JavaScript is here.
You could probably also use an NSTextView and embed the button and star rating as NSTextAttachment objects but this is quite complex, it would be a lot easier to use a WebView.
The only other alternative that I can see is writing a view controller that manages the layout of the controls based on the current size of their container view. You would need to measure the text to do this and one way to do that is to use the excellent NS(Attributed)String+Geometrics category written by Jerry Krinock.
I'm completely stumped with this problem. I made a custom search control that uses a few different classes. For some reason, when an NSTextField is anywhere over these different pieces, it displays a solid black border around it, and the cursor doesn't blink.
If anyone has a couple minutes - I've put together my code on pastebin.
Here's a picture of the search control, and what it looks like in this particular case:
The search control is sitting on top of a gradient view:
http://pastebin.com/m43fde2b6
The search control is pieced together with this code:
http://pastebin.com/m5be08c32
The actual graphical part of the search control is built from two classes:
http://pastebin.com/m5bfa9439
http://pastebin.com/m5e909a2f (extends above class)
I cannot find what the heck is wrong. The text works, but there's a black border, and the cursor doesn't blink. What am I doing wrong?
Arg, I've been pulling my hair out for days on this one.
Putting one view over a sibling view has never been well-supported in Mac OS X. Try making it a subview instead. You may even want to make it a private component of a dedicated search-field view.
On that note, is there a reason you're not using NSSearchField?
I got it figured out! Finally.
What I didn't realize was the the "drawRect:" method's parameter "dirtyRect", is the portion of the control that is "dirty", meaning it needs to be redrawn.
So, when an NSTextField is on top of a control, it will trigger that control's "drawRect:" to be called (3) different times - with different "dirtyRect" parameters.
1: the cursor - usually an NSMakeRect(textField.origin.x,textfield.origin.y,1,textfield.origin.height).
2: the text field frame
3: the size of the control the text field is sitting on.
So, the fix was simple, change my control's scale 9 drawing to always draw to [self frame]. You can see the change here: http://pastebin.com/m50a5b0ad (line 89).
Previously, it was drawing to the "rect" parameter (http://pastebin.com/m5e909a2f - line 88), but depending on where the drawRect call was coming from, the rect parameter was different sizes.