I’m trying to put together what seems to be a simple case of two NSTextFields with dynamic width and fixed spacing in between. I cannot figure out an effective way to do so though.
I’m looking to get something like this:
The blue boxes are the NSTextFields. When more text is entered into one, it should grow and thus make the other one shrink, maintaining the lead space, trailing space and the spacing in between the fields. The first one should take the priority if both of the fields have too much text. Each field will also clearly have a maximum and a minimum possible width it can reach.
How would I go around handling this, preferably utilising IB autolayout as much as possible?
It seems to me that all of constraints you mentioned directly translate into interface builder --
First view has width >= something.
First view has width <= something
Same for Second view.
Space between views is fixed.
Second view wants to be as small as possible (have its width at 0) but this has lower lower priority than the previous constraints and lower priority than inner content size constraints.
The code I had to add to my view controller, after applying the constraints as per the ilya’s answer:
In controlTextDidChange (_controlWidthConstraint refers to the fixed width constraint of the input; it’s probably 0 by default for the second input):
// Get the new width that fits
float oldWidth = textControl.frame.size.width;
[input sizeToFit];
float controlWidth = textControl.frame.size.width;
// Don’t let the sizeToFit method modify the frame though
NSRect controlRect = textControl.frame;
controlRect.size.width = oldWidth;
textControl.frame = controlRect;
_controlWidthConstraint.constant = controlWidth;
The key lies in invalidating the intrinsicContentSize for the text field when text is input.
You can check a sample project here, to get you on the right track.
Related
Say you have a UICollectionView with a normal custom UICollectionViewLayout.
So that is >>> NOT <<< a flow layout - it's a normal custom layout.
Custom layouts are trivial, in the prepare call you simply walk down the data and lay out each rectangle. So say it's a vertical scrolling collection...
override func prepare() {
cache = []
var y: CGFloat = 0
let k = collectionView?.numberOfItems(inSection: 0) ?? 0
// or indeed, just get that direct from your data
for i in 0 ..< k {
// say you have three cell types ...
let h = ... depending on the cell type, say 100, 200 or 300
let f = CGRect(
origin: CGPoint(x: 0, y: y ),
size: CGSize(width: screen width, height: h)
)
y += thatHeight
y += your gap between cells
cache.append( .. that one)
}
}
In the example the cell height is just fixed for each of the say three cell types - all no problem.
Handling dynamic cell heights if you are using a flow layout is well-explored and indeed relatively simple. (Example, also see many explanations on the www.)
However, what if you want dynamic cell heights with a (NON-flow) completely normal everyday UICollectionViewLayout?
Where's the estimatedItemSize ?
As far as I can tell, there is NO estimatedItemSize concept in UICollectionViewLayout?
So what the heck do you do?
You could naively just - in the code above - simply calculate the final heights of each cell one way or the other (so for example calculating the height of any text blocks, etc). But that seems perfectly inefficient: nothing at all of the collection view, can be drawn, until the entire 100s of cell sizes are calculated. You would not at all be using any of iOS's dynamic heights power and nothing would be just-in-time.
I guess, you could program an entire just-in-time system from scratch. (So, something like .. make the table size actually only 1, calculate manually that height, send it along to the collection view; calculate item 2 height, send that along, and so on.) But that's pretty lame.
Is there any way to achieve dynamic height cells with a custom UICollectionViewLayout - NOT a flow layout?
(Again, of course obviously you could just do it manually, so in the code above calculate all at once all 1000 heights, and you're done, but that would be pretty lame.)
Like I say above the first puzzle is, where the hell is the "estimated size" concept in (normal, non-flow) UICollectionViewLayout?
Just a warning: custom layouts are FAR from trivial, they may deserve a research paper on their own ;)
You can implement size estimation and dynamic sizing in your own layouts. Actually, estimated sizes are nothing special; rather, dynamic sizes are. Because custom layouts give you a total control of everything, however, this involves many steps. You will need to implement three methods in your layout subclass and one method in your cells.
First, you need to implement preferredLayoutAttributesFitting(_:) in your cells (or, more generally, reusable views subclass). Here you can use whatever calculations you want. Chances are that you will use auto layout with your cells: if so, you will need to add all cell's subviews to its contentView, constrain them to the edges and then call systemLayoutSizeFitting(_:withHorizontalFittingPriority:verticalFittingPriority:) within this "preferred attributes" method. For example, if you want your cell to resize vertically, while being constrained horizontally, you would write:
override func preferredLayoutAttributesFitting(_ layoutAttributes: UICollectionViewLayoutAttributes) -> UICollectionViewLayoutAttributes {
// Ensures that cell expands horizontally while adjusting itself vertically.
let preferredSize = systemLayoutSizeFitting(layoutAttributes.size, withHorizontalFittingPriority: .required, verticalFittingPriority: .fittingSizeLevel)
layoutAttributes.size = preferredSize
return layoutAttributes
}
After the cell is asked for its preferred attributes, the shouldInvalidateLayout(forPreferredLayoutAttributes:withOriginalAttributes:) on the layout object will be called. What's important, you can't just simply type return true, since the system will reask the cell indefinitely. This is actually very clever, since many cells may react to each other's changes, so it's the layout who ultimately decides if it's done satisfying the cells' wishes. Usually, for resizing, you would write something like this:
override func shouldInvalidateLayout(forPreferredLayoutAttributes preferredAttributes: UICollectionViewLayoutAttributes, withOriginalAttributes originalAttributes: UICollectionViewLayoutAttributes) -> Bool {
if preferredAttributes.size.height.rounded() != originalAttributes.size.height.rounded() {
return true
}
return false
}
Just after that, invalidationContext(forPreferredLayoutAttributes:withOriginalAttributes:) will be called. You usually would want to customize the context class to store the information specific to your layout. One important, rather unintuitive, caveat though is that you should not call context.invalidateItems(at:) because this will cause the layout to invalidate only those items among the provided index paths that are actually visible. Just skip this method, so the layout will requery the visible rectangle.
However! You need to thoroughly think if you need to set contentOffsetAdjustment and contentSizeAdjustment: if something resizes, your collection view as a whole probably will shrink or expand. If you do not account for those, you will have jump-reloads when scrolling.
Lastly, invalidateLayout(with:) will be called. This is the step that's intended for you to actually adjust your sections/rows heights, move something that's been affected by the resizing cell etc. If you override, you will need to call super.
PS: This is really a hard topic, I just scratched the surface. You can look here how complicated it gets (but this repo is also a very rich learning tool).
I want to draw single line textfield with default border.
So I entered some multiline text into it(just for test for future cases) and set the flags
Swift:
textfield.usesSingleLineMode = true
textfield.maximumNumberOfLines = 1
Objective-C:
self.textfield.usesSingleLineMode = YES;
self.textfield.maximumNumberOfLines = 1;
But I got in console:
(lldb) po self.textfield.intrinsicContentSize
(width = 511.5, height = 174)
I've tested all lineBreakModes, including NSLineBreakByTruncatingTail.
Here is a field in IB:
Of course I can:
Overload intrinsicContentSize method
Filter strings keeping only first line
But it looks like a crutch =( Do you have any ideas how to fix it without crutches? Do you think it is an AppKit bug or my mistake?
PS In any case, thanks for attention.
This is not a bug. By default the NSTextField is trying to display as much text possible. I made a sample application, that contains a long line of text in the title of the NSTextField. Set it to "Uses Single Line Mode" and set line break to "Truncate Tail". I put leading, top and trailing layout constraints on the view. Now when i input the text into the text field, it will make the horizontal width of the window very wide. This is Autolayout in action.
To fix this you need to select the NSTextField, choose the Size inspector and set the Horizontal Content Compression Resistance Priority to a lower number. In the sample application I changed it from 750 to low (250).
Resize content view to an acceptable size, and you are off to the races.
I am having trouble preventing the text inputs from overlapping the footer button.
The footer has been anchored to the bottom of the screen. All the elements up top (logo, title label, and 2 input boxes) all have relative constraints. I try to add a constraint between that last input and the footer button but it pushes the footer off the screen on the smaller iphone.
What do I do??
https://github.com/civilordergone/taskfort_ios
Your issue seems to be in landscape only (I ran your code), where you have, for example, 320 points of vertical space, and an image (128pt), a text label (120pt), two text fields (30 each, for 60pt in total) and a 30pt button at the bottom. Already that's 338pt used, and we haven't accounted for the vertical spacing between your objects.
There simply isn't enough vertical space for all of these items to be vertically positioned while retaining their heights, so something has to be flexible: something has to be able to be vertically shrunk/compressed. Your logo and app name (Taskfort) are two candidates.
Here are some of the changes and/or points of consideration:
An ImageView with a height and a width equality constraint will always be that size, but for your layout, it has to be able to be compressed. I removed the height & width constraints and added an Aspect Ratio constraint, so the logo keeps its aspect ratio, but can now scale. I added a relationship constraint between the logo's left side and the left side of the Taskfort label.
The image has a relationship to the top of the screen, saying it must be equal or greater (not less than) to 0. This just means "the image can't be pushed off the top", which "less than" would allow it to be. (For example, if the image is pushed off the top by -40 points, that's still "less than 20").
The image has to be allowed to be vertically compressed. There is a property for "Vertical Compression Resistance" that was 250, and is now 249. By setting it to 249, we're saying "If something has to give way, vertically, this object can be compressed." Since we defined an aspect ratio constraint, if it does get compressed vertically, it'll be reduced horizontally by a proportionate amount so as to maintain the proportions of the logo.
To prevent the text fields from overlapping, their relationships are set to "equal or greater than". Same for the Username text field to the label.
The challenge was in defining the relationship between Password and the Create Password button at the bottom. I added a constraint that says their vertical distance must be greater than or equal to 20. This has a priority of 1000 (by default), so at all times, you get 20pt or greater between those two. Without this, your password field and your button overlap.
While step 5's constraint solves the overlap problem, it creates a new one in portrait orientation, where the password is now 20pt from the button, instead of being lovely white space. To fix that, we add a second constraint between the password field and the button, and specify that the vertical distance is to be 228pt between them both. Now that creates a constraint conflict because you now have two constraints that are both trying to define the vertical relationship between the button and the text field. The 20-pt one is required, it has to be there. But the other one is just a "nice to have, if we can fit it".
So you set the priority of the new one (the 228pt) to be low, such as a Priority of 250. Then the layout engine will use the required one (must be 20 pt or greater) and then it sees the other one ("make them 228") and it tries to do that. If it can't, such as in landscape, then it doesn't do it and doesn't complain, because you have the other constraint already that provides positioning information. If you're in portrait and you have enough space such that it can also apply the low priority constraint, then it'll do that too, and your portrait layout now gets a bigger gap between top and bottom.
When testing these layouts, use the Assist Editor in Preview split-screen mode so you can see the affects of your changes without needing to run the simulator. Here's a guide on that.
Sounds like you're using an equality constraint, such as "the distance between lastInput.bottom and footer.top equals 20". Instead, try an inequality operator, such as "the distance between lastInput.bottom and footer.top is equal or less than 20".
The attributes inspector for a constraint can let you change an equality to an inequality. Alternatively, you can double-click the constraint line (the UI in the storyboard editor) to get a quick pop-up for that.
I have designed my help page for my application,it contains some FAQs..so I have used UILabels for question and answer,I have adjusted,x,y,width and height exactly in the xib,leaving a gap between a question and answer and answer and next question.so totally I have some 10 question and answers,I have put them inside a scroll view.
But now, suppose the text changes dynamically, how can I adjust the positions and width and height,is a problem which I am not able to figure out, by using the below code,it adjusts the height and width of a particular label,if the text increases
NSString * test=#" It may come as a rude shock, but Facebook users should not feel surprised if tomorrow they come across their photos existing in the web world despite having deleted them personally long ago.";
m_testLabel.text = test;
m_testLabel.numberOfLines = 0; //will wrap text in new line
[m_testLabel sizeToFit];
but then, my next label will clash with it..is their any way so that all the labels get adjusted according if the width of any label increases or decreases?
Hope you all have understood my question..
Did you look into the below function, pass the font you have used and the size to which u want to constraint the label into.
- (CGSize)sizeWithFont:(UIFont *)font constrainedToSize:(CGSize)size
I have a Zedgraph textobj which I want to place always in the same x, y position (ASP.NET image). I noticed that the text doesn't always show in the same starting x position. It shifts depending on the text's length. I tried to have the text to have the same length by padding it with spaces. It helped a little but the result is not always consistent. I am using PaneFraction for coordType.
What's the proper method to have a piece of text to always show in the same x position. I am using textobj as a title because the native title property always shows up centered and I need my title be left aligned to the graph.
No, it does not depend on text lenght, however...
It depends on various other things:
Horizontal and vertical align of the text box (see: Location )
Current size of the pane. The font size is scaled dynamically to fit the changing size of the chart.
Counting proper positions to have TextObj (or any other object) always at the same place is quite hard. So you need avoid as much as you can any numbers/fractions in your location coordinates. ZedGraph sometimes calculates the true position in quite odd way then.
You haven't provided any code, so it's hard to tell if and where you made the mistake (if any). But, if I were you, I would do something like that:
TextObj fakeTitle = new TextObj("some title\n ", 0.0, 0.0); // I'm using \n to have additional line - this would give me some space, margin.
fakeTitle.Location.CoordinateFrame = CoordType.ChartFraction;
fakeTitle.Location.AlignH = AlignH.Left; // Left align - that's what you need
fakeTitle.Location.AlignV = AlignV.Bottom; // Bottom - it means, that left bottom corner of your object would be located at the left top corner of the chart (point (0,0))
fakeTitle.FontSpec.Border.IsVisible = false; // Disable the border
fakeTitle.FontSpec.Fill.IsVisible = false; // ... and the fill. You don't need it.
zg1.MasterPane[0].GraphObjList.Add(fakeTitle);
I'm using ChartFraction coordinates instead of PaneFraction (as drharris suggests) coordinates to have the title nicely aligned with the left border of the chart. Otherwise it would be flushed totally to the left side (no margin etc...) - it looks better this way.
But make sure you didn't set too big font size - it could be clipped at the top
Are you using this constructor?
TextObj(text, x, y, coordType, alignH, alignV)
If not, then be sure you're setting alignH to AlignH.Left and alignV to AlignV.Top. Then X and Y should be 0, 0. PaneFraction for the coordType should be the correct option here, unless I'm missing your intent.
Alternatively, you can simply download Zedgraph code, edit it to Left-align the title (or even better, provide an option for this, which should have been done originally), and then use it in production. Beauty of open source.