For a MacOS app, I have a Window, containing an NSView; into that view, I want to add a subview with a constant size and height.
When loading the subview programmatically by [myView addSubview:mySubview], I want the NSView *myView that is hosting the subview to change in size so it accomodates the subview, and the window to change in size accordingly; so that the edges of the NSView inside that Window keep the same distance to their surroundings in the Window as before. How do I achieve that most efficiently and which properties do I have to specify in IB to make that work? Do I have to adjust the size of myView and of the Window programmatically by hand or can I achieve this in a more beautiful way?
There are multiple ways to achieve this.
A simple one is to set autoresizingMask the value(s) you want.
The mask you can see in Interface Builder are represented by predefined numbers (NSAutoresizingMaskOptions) that you will combine with bit operation
view.autoresizingMask = NSViewMaxXMargin | NSViewMaxYMargin;
which is simmilar to Autoresizing like in this screenshot of IB
The checkmark on Layout Translates Mask Into Constraints has to be made, either in IB or programmatically so they are used as constraints.
view.translatesAutoresizingMaskIntoConstraints = YES;
The relative positioning to its enclosing superview is defined when the view is instanced with -initWithFrame: with the given frame or with the values set in IB when it creates an instance and inits the UI element via -initWithCoder: .
Be aware this does not stop the autolayout mechanism of IB to warn you that your desired coordinates, sizes and constraints are maybe clashing with constraints.
As suggested by #Willeke, I needed to understand and apply Autolayout. To make it work in IB, I set the autoresizingMask of my subview to stick to all for sides and automatically adjust width and height. Even though it can be done completely in IB, I think programmatically this would be
subview.autoresizingMask = NSViewWidthSizable | NSViewHeightSizeable;
As pointed out by #Ol Sen in his answer, Translates Mask Into Constraints also has to be activated.
To arrange the elements inside that subview that is added programmatically as described in the opening post, I rely on nested stackviews and resize them instead of resizing the parent.
The only problem left is to correctly adjust the frame of the subview to match the parent view before adding it. If this step is left out, the contraints the autoresizing mask of the subview is translated into when adding it will result in the correct resizing behaviour, but wrong margins. The essential code looks like this:
MySubViewController *subViewController = [[MySubViewController alloc] init];
subViewController.view.frame = superView.bounds; // Correct the margins
[superView addSubview:subViewController.view];
Related
I am developing in Cocoa, and I am currently having problems with filling the background of a NSWindowController.
I understand that subclassing is the way forward if you want to customise your cocoa app. So I created a custom NSView named whiteView and added this view as a subview to my windowController's contentView; however, there are some issues with completely filling the background of the window. Can anyone explain how I can have the color cover the complete surface area of the window's frame pls. Thank you
These are the results that I have so far.
1) This is the window when I leave it as it is, notice the white color only having covered half of the window.
2)Here is the same window again when I adjust the window far to the right and bottom. The white screen seems to stretch enough so that it covers the elements.
This is how I create the custom view
- (void)drawRect:(NSRect)dirtyRect
{
[super drawRect:dirtyRect];
[[NSColor whiteColor] set];
NSRectFill([self bounds]);
}
And this how I achieve plaster the view onto my window.
WhiteView *whiteBackgroundView = [[WhiteView alloc] initWithFrame:self.window.frame];
[self.window.contentView addSubview:whiteBackgroundView positioned:NSWindowBelow relativeTo:self.window.contentView];
What do I need to do to correctly allow for my window's background to be fully covered in white?
First, the simple solution is to use -[NSWindow setBackgroundColor:] to just set the window's background color. No need for a view.
If you're still interested in how to fix the view-based approach, probably what's wrong is that you haven't set the autoresizing mask of the view to make it follow the changes in the window size. For example, you could do [whiteBackgroundView setAutoresizingMask:NSViewWidthSizable | NSViewHeightSizable].
However, you could also set the whiteBackgroundView as the window's contentView rather than as a subview of it. The window's content view is always kept at the size necessary to fill the window's content rect. All of the other views of your window would be subviews of the white background view. In my opinion, this is better than making it a sibling that just happens to be at the back. Using relative ordering among siblings views to achieve a particular rendering order is a hack.
Finally, there's no reason to invoke super's implementation in your -drawRect: if the superclass is NSView itself. NSView doesn't do any drawing in its -drawRect:. Also, your subclass takes over full responsibility for the entire drawn contents of its bounds, so you'd overdraw whatever super had drawn, anyway. (Also, you need only fill dirtyRect rather than [self bounds].)
While you're at it, since your class fills its bounds, you should override -isOpaque to return YES for optimization.
Update: regarding the frame of the view: if it's not going to be the window's content view, then you want to set its frame to be its prospective superview's bounds. So, you should have used self.window.contentView.bounds if you wanted whiteBackgroundView to fill the content view.
More generally, if you want the content rect of a window, you would do [window contentRectForFrameRect:window.frame]. But if a view is going to be a window's content view, there's no need to set its frame to anything in particular. It will be resized automatically.
Update 2:
To transfer the view hierarchy from the original content view to the new content view (when you're making the white background view the content view):
NSArray* subviews = [self.window.contentView.subviews copy];
[subviews makeObjectsPerformSelector:#selector(removeFromSuperview)];
[whiteBackgroundView setSubviews:subviews];
[subviews release];
(Written for manual retain-release. If using ARC, just drop the -release invocation.)
Regarding the frame to use, as mentioned in the first update: keep in mind that the view's frame should be expressed in the coordinate system of its superview. So, as I said, self.window.contentView.bounds would work if you're putting the new view into the content view. The window's frame and content rect are in screen coordinates. They would be completely incorrect for positioning a view.
I am doing my first steps creating applications in iOS, so maybe I am asking a dumb question.
In a View Controller, I put some buttons and text fields to make different actions. To improve the organization, I want to put several backgrounds with borders to delimitate the areas where the buttons and text fields are placed.
I tried putting a text label without text and color background, and move my objects over it, but I don't know why the layer is placed over the buttons and text fields. Then, I tried modifying the text label's opacity, but it's totally unsatisfactory.
label1.layer.cornerRadius = 5.0;
label1.layer.masksToBounds = YES;
label1.layer.borderColor = [UIColor lightGrayColor].CGColor;
label1.layer.borderWidth = 1.0;
label1.layer.opacity = 0.1;
label1.layer.backgroundColor = [UIColor whiteColor].CGColor;
Can help me anyone to find a better way to do this or improve my code?
1) you could just use a normal UIView instead of a label with no text (same difference just more correct)
2) in the story board the order in which the UI elements are on the left bar is important, it is basically the draw order of the elements, the ones at the top are drawn first, therefore things below it will be drawn over
You can try in Interface Builder to put multiple UIImageView objects and set your backgrounds as desired from Attributes Inspector and watch out how you put your elements in your UIView. The ones below are drawn after the ones at the top.
If I understood you right, ...
Make yourself familiar with the logic behind the subview hierarchy and the drawing sequence of siblings.
In your interface builder/storyboard you could align the views as followed:
UIView (the default view that is connected to the view controller's view property)
\--UIView (This is a background to group UI Items as buttons or Lables
\-- UILabel
\-- UIButton
\--UIView (the next background)
\-- UILabel
\-- UIButton
When it comes to coorindates then you will notice that the coordinates of each view are relative to its subview. So the UILabel and UIButton might have the same coordinates but each of them will be located within its very subview.
Another option would be:
UIView (the default view that is connected to the view controller's view property)
\--UIView (Background)
\--UIButton
\--UILable
\--UIView (Background)
\--UIButton
\--UILable
Or even
UIView (the default view that is connected to the view controller's view property)
\--UIView (Background)
\--UIView (Background)
\--UIButton
\--UILable
\--UIButton
\--UILable
In that case all UI elemets share the same coordinate space. In that case you need to care for a proper layout.
This one is would not work:
UIView (the default view that is connected to the view controller's view property)
--UIButton
--UILable
--UIButton
--UILable
--UIView (Background)
--UIView (Background)
Even if all coordinates etc. are identical with those of the examples above, the two background views would hide the other UI elements just because they are drawn after the others. And the last one wins the space.
I'm trying to make a rotation on a tableview to tilt the table (to give the effect of a 3d text crawl similar to the star wars opening crawl).
After looking around I found this question objective-с CALayer UIView real rotation
and the accepted answer seems to do what I want, however when I apply the code to my TableView it does nothing and the table appears as usual.
This is the code I am copying:
float distance = 50;
CATransform3D basicTrans = CATransform3DIdentity;
basicTrans.m34 = 1.0 / -distance;
_tableView.layer.transform = CATransform3DRotate(basicTrans, M_PI_4, 1.0f, 0.0f, 0.0f);
I'm placing this in my viewDidLoad method after creating my array of Strings (that populate the tableView)
I currently only have three other methods in the Controller:
didReceiveMemoryWarning (automatically addd when project created)
tableView: numberOfRowsInSelection (used for setting up the table view)
tableView: cellForRowAtIndexPath (used for setting up the table view and setting the cells text form the array)
My understanding is that the tableview has a CALayer, and that the CATransform3D manipulates this to give the representation of the view in a 3d space. If my understanding is correct then I don't get why the list is shown normally on screen? I appreciate the numbers my not give the effect I want yet but they should at lest effect the appearance of the tableView on screen.
Also I have imported QuartzCore etc and added it in linked frameworks
Solution is to use the code marked as OLD answer in the the - (UITableViewCell *)tableView: cellForRowAtIndexPath: method after the cell is checked for being null.
Since the approach suggested below has not worked, another thing I would try out is applying the transform to the UITableView's subviews. Actually, UITableView is a UIScrollView, so it is just a container for subviews that make up the real content of the table view. I would try something like this:
for (UIView* subview in tableView.subviews) {
subview.layer.transform = ...;
}
I have never inspected a table view subviews hierarchy, so I cannot say whether this will work or you should rather apply the transform to just one of the subviews, but I hope this can lead you in the right direction.
OLD ANSWER:
You could try setting your table view's layer sublayerTransform instead of `transform':
You typically use this property to add perspective and other viewing effects to embedded layers. You add perspective by setting the sublayer transform to the desired projection matrix. The default value of this property is the identity transform.
(source).
I am suggesting this based on the hypothesis that a UITableView has quite a complex structure in terms of subviews, so transforming just the view's layer might have no effect. I haven't tried it, though, so I cannot guarantee it will work.
I am new to cocoa /objective-C coming from Java/C# and C/C++ . Cocoa has been giving me lots of headaches. I have read an apple's article on View hierarchy in cocoa. But still confusions.
I need to know when I add a subView to a view programatically not via interface builder. Where exactly will the view be placed relative to other subviews assuming there are other subviews in the same parent view.
In java there are layout managers, in C# there is also vertical/horizontal panel etc, so we know if I add an item/control it will be going to the right of the existing item or to the bottom of it.
So if I do as shown in the following line what exactly determines where the new subview will be placed ??
[[window contentView] addSubview:newView];
Thanks,
The frame of the view defines the rect that it occupies in its superview's coordinates, so its position will be frame.origin. That can be set either before or after you add the subview.
This is spelled out fairly clearly in the View Programming Guide.
It depends on whether you are using Autolayout or not.
If you are not, then when you create a view you call -[NSView initWithFrame:(NSRect)frame] and that frame will will define where the view appears in the superview's coordinates.
_view = [[NSTextField alloc] initWithFrame:NSMakeRect (50, 50, 100, 50)];
will make an NSTextField size 100x50 and it will be placed 50,50 pixels inside the superview.
If you are using Autolayout, then the position of a view depend entirely on what layout constraints apply to it. With Autolayout any frame that you set will be ignored. While autolayout has a steep learning curve, once you set your constraints, it (in theory) means you can ignore the layout.
The frame rectangle gives the view's size and position in the superview. The frame is at position 0,0 (x,y) with a size of 0,0 (w,h) by default. The position in the subview collection is entirely ignored except in rare cases like NSSplitView.
Cocoa doesn't automatically align any views. There is no initial layout mechanism like in .net or java.
You have to position all your views manually by setting their frames in points.
By default, the origin of a fresh initialized view is at (0,0).
AFAIK, the documentation and header file don't specify exactly the origin (x,y) the added subview will be placed. What I do after add a subview is to calculate a new origin (and if applicable) size before repositioning the subview using CGRectMake().
I have my view set up in viewDidLoad. All the different frames and such of the subviews have been defined relative to self.view. Therefore it doesn't matter what size self.view is the subviews will always shrink or expand to fit (as it were).
So when I rotate my device I want the view to rotate (easy enough with shouldAutoRotateToInterfaceOrientation:...) but the subviews stay the same shape.
Calling [self viewDidLoad]; makes all the elements fit, but puts a new layer on top of the previous layout (which is obvious... but i'm just saying to explain what I mean).
Is there any way to refresh the frames of the subviews or something? I don't know what other people do to be honest. Am I going to have to put ALL of my views into the .h file as properties and do everything manually on didRotate...?
You have three options:
If autoresizing masks are good enough to position your views, assign the correct autoresizing mask to each subview when you create them.
If autoresizing masks are not sufficient, override willAnimateRotationToInterfaceOrientation:duration: and reposition your subviews in that method. I would create a custom method that takes the orientation as a parameter and is responsible for laying out all subviews. You can then call this method from willAnimateRotationToInterfaceOrientation:duration: and from viewDidLoad.
You could also create a custom UIView subclass and make your view controller's view an instance of this class. Then override layoutSubviews to position all subviews depending on the view's size. This approach implies that your custom view manages its subviews instead of the view controller.