I currently have a split view and when i resize the app window i want only the right subview to get larger (so left stays exactly the same size). I have a nstextfield in the right subview where i can type stuff in. However, in certain circumstances I call [_textFieldInQuestion setEditable: NO]. After doing so, when i try to resize the app, the right will get larger up till a certain point, then the left will grow. I saw a post on SO where I should subclass the nstextfield to achieve the behavior, but i was wondering if there were any alternatives that were more elegant and if not, how does one go about override the autolayout methods to produce the behavior i described.
When a text field is non-editable, it has an intrinsic width based on its content. (When it's editable, it doesn't make sense for the text field's width to track its content because its content is not "intrinsic".)
The text field's horizontal Content Hugging priority is presumably higher than the Holding priority of the left view of the split view. So, the text field resists "stretching" to be wider than its content at a higher priority than the left view resists being increased in size.
Reduce the text field's horizontal Content Hugging priority and/or increase the left view's Holding priority so that the former is greater than the latter.
Related
I want to create a custom UIView that would be equivalent to a horizontal UIPickerView. The data elements, such as "Mountain View, Sunnyvale, Cupertino, Santa Clara, San Jose" would move left to right. The view would be long and thin. 50px in height, 350x in width sort of thing.
I will need to use protocols to obtain my datasource elements likely, but what I'm more interested in figuring out is the visual aspect of this.
How would I animate things left and right? Should I just make one incredibly long view (off screen), and change the frame left and right. This seems like a bad idea, as likely only 3-5 options need to be visible in the control at one time. If the datasource is 100 elements, there is no point in loading the other 95 off screen in a long view.
So perhaps I should load ~9 or something. The 3-5 on screen, plus an additional ~3 left and right. Each time the control is triggered to move left and right, it will load up another element on the view(?).
Is this a good way to achieve this? A long thin view with ~9 UILabel's. As the control moves to the right, I would shift the further left UILabel to move hidden to the far right, and change the UILabel to be the next in the data source.
I also likely want to change the text size based on its position. If it's currently selected, I either want to bold it and possibly increase the font size. How can I gradually achieve this as the view is moved? It would be weird if the text only changed once it was moved perfectly center inside the view. It should likely gradually grow as it gets closer to the middle.
How can I achieve this?
A collection view would do the trick, obviously there's some coding involved.
I'd suggest you to take a look at the code of, or use, the following library.
I've used it once,does almost exactly what you need and works very well:
AKPickerView
I am working on OS-X app, and I need advice on the window size.
Before someone to jump and declare this question as duplicate, I have read this post:Window Size for Mac application but it didn't help me to solve my issue.
My issue is the following. I use NSTableViews to display some of the data. However in some windows, I am getting horizontal scroll bar in the NSTableView due the numbers of the columns.
Things to be worse, the data in some of the columns are not completly visible, you have to resize the column to reveal the complete text in that cell / column.
I am thinking of increasing the initial window size, but I can't decide how much.
My current window size is 1024 x 768. User can make the app full screen, and window can be resized to be larger than this size, but not smaller.
Any help will be deeply appreciated.
Regards, John
For the table, you should set minimum widths for each column. Select each column in the document outline and view the Size inspector. You should also review the Resizing pop-up on the Attributes inspector.
Similarly, you should review the Column Sizing pop-up on the Attributes inspector for the table view itself.
With respect to the window size, I recommend that you use auto layout if you're not already. Apply appropriate constraints to all of the view, ultimately relating them (directly or indirectly) to the window's content view. Then, don't set a minimum size for the window itself. Let the constraints impose an effective minimum (and potentially even maximum) size.
The trick though, is that not all views will have an intrinsic minimum size. For example, the table view itself may not get any narrower than the sum of the minimum widths of its columns, but it's in a scroll view. The scroll view is allowed to get narrower than the table view, resulting in horizontal scrolling. So, you may need to add an explicit minimum width constraint to the scroll view.
If you set constraits for text inside the rows, you may get some horizontal scrolls. But if you set the constraits for the app elements like UITableView to the borders of the app window, you may resolve this issue.
How do I tell an NSScrollView that wraps an NSTextView to grow with the NSTextView until a maximum?
== In more details:
The UI is common in many messanger/chat app. Initially, the NSTextView is empty and has just enough height to show one line of text. The NSScrollView is just enough to fit the NSTextView. As the user type in more text, the NSScrollView should grow along with the NSTextView, until reaching a maximum height, then start showing the vertical scroll bar.
Observe NSTextStorageDidProcessEditingNotification on the text storage of the text view. Then call usedRectForTextContainer on the layout manager to determine how large the text is for the view's text container.
You may also need to add extraLineFragmentRect to it, I'm not sure. That's also available from the layout manager.
So, i am new to xcode and iOS7 and i'm trying to create simple container with two elements inside.
I prefer to make it 100% programmatically. (no IB)
I want to create container with two elements Image and Label.
I want to achieve variable width depends on the text element inside.
Here is example:
Based on user action i want to change text on the fly. Let's assume longer text, and main container have to change width too.
And now the question is: What is best approach to to that?
UIView with subviews or something else i'm just expecting direction.
Code examples with be gratefully appreciated.
Thank you in advance.
What you have described is exactly what a UIButton does automatically: it is a container containing an image and a title (text) and it resizes itself automatically when the text changes.
Let us assume, however, that you want to do this yourself. That is, let's say you want a UIView ("container") containing two other UIViews (subviews). Then we need to discuss this requirement:
Based on user action i want to change text on the fly. Let's assume longer text, and main container have to change width too.
This is not going to happen automatically. You can use constraints (auto layout) to describe the size / position of the subviews in relation to the superview, but it works the other way: the superview changes, and the subviews obey. So you will have to change the superview size manually after you change the text.
You can still use auto layout to help you. Let's say the text is in a UILabel. Well, a UILabel wants to change width automatically when the text changes. So far so good. But you must still change the container view width yourself. You can call systemLayoutSizeFittingSize: to learn what the size of the container should be, using constraints, working from the inside out; but then you will have to change its size yourself to that size.
(You can easily create the view, the subviews, and the auto layout constraints in code.)
If you don't want to use autolayout, then you will just calculate the sizes and positions of everything when the text changes and adjust it all yourself (in code). You can learn the size the label needs to be, to fit its text, by calling sizeThatFits: (or sizeToFit which will actually resize it correctly).
I have a window whose size I need to change when the user clicks on it. I am using [self setFrame:windowFrame display:YES animate:YES] to accomplish this.
Even though the window successfully changes size (I increase its height), it moves the contents of the window up with it. How do I prevent this from happening? I want the contents to remain in place.
I am on OSX Mountain Lion developing an app for OSX using Objective-C and Cocoa.
EDIT: Constraints and/or Springs and Struts will not work as I need to move the contents around after the window is resized.
Constraints and/or Springs and Struts will not work as I need to move the contents around after the window is resized.
In that case, you should use NSViewAnimation.
A single view animation can actually perform multiple animations to multiple views, and you can even do one to a window, despite the class's name and the fact that windows aren't views in Cocoa.
You create a view animation with initWithViewAnimations:, which takes an array of dictionaries. Each dictionary identifies the target (NSViewAnimationTargetKey) and what to do to it: Either change the target's frame (NSViewAnimationStartFrameKey and NSViewAnimationEndFrameKey) or fade the target in or out (NSViewAnimationEffectKey). For your case, you'll be changing the targets' frames.
When the user does the thing that causes the resize of the window, you'll need to compute the desired overall size of the window (taking care to adjust its frame's position so it doesn't grow off the screen), as well as the new frames—both positions and sizes—of your views. Everything that will move and/or change size, create a dictionary for it and throw it into the array. Then create the view animation.
An NSViewAnimation is a kind of NSAnimation, which provides all the methods for starting and stopping the animation, monitoring its progress, hooking into it, and chaining multiple NSAnimations together. If nothing else, you'll need to start the animation.
If you are using the Interface Builder to build these views, then I believe one approach is to set the "struts and springs." These are available under the "size inspector" and are the red arrows and bars above the "autosizing" label. Play around with these to get the effect that you want, but the general idea is that the arrows control how the size of the view adjusts to changes in the size of the parent view, and the bars control the relationship of the edges of the view to the edges of the parent view as the size changes.
In constraint-based layout, set the views around the edge of your window to be a fixed distance from their superview's edge.
Xcode will infer a lot of resizability from that; if anything still isn't resizing properly, adjust its constraints so that its width and/or height is no longer constant.
The easiest way is to move your views until blue lines show up in the editor. Each blue line corresponds to a rule in the HIG about how things should be lain out, and if you drop the view there, Xcode will create constraints matching those guidelines. For example, if you set a view 20 points from the right edge of its superview, you'll get a blue line for that, and if you drop the view there, you'll create a constraint that the view must remain that distance from that edge.
The superview isn't the only view with which you can create HIG-based constraints. You can also create guideline constraints between sibling views. For example, if you put a button next to another button at the appropriate distance, you'll get a blue line across that distance, and if you drop it, you'll create a constraint that those two buttons must remain that distance from each other.
If you want to do something really custom, the three buttons in the lower-right corner of the nib editor will let you create any constraint you want. What you have selected determines what constraints you can create; the nib editor's outline view will help you make sure you have the selection you want.
You are going to have to iterate through all of your subviews and change their frame positions based on the delta of your window frame.
so if you expand your window frame by 20 in all directions, all your subviews are going to have to increase their frame positions by (20,20) to offset the windows movement.