I was wondering if anyone knew why IB has inexplicable high lighted areas on the odd nib here and there..
Below is an example:
What I mean is that light area within the area I marked out in red...
There's no views below the split view, there's no bounds which correspond to it and so far there's nothing complaining about "misplaced views" etc... What is it?
update: recently I worked out when it last happened that that weird "area" is always the same size as the rightmost NSView (whether its embedded in a NSSplitView or just 2 NSViews side by side.
Many thanks
Adrian S
It's due to a bug in XCode Interface Builder. And in my experiments it's been predictable according to the following explanation:
The lighter colored area is intended to highlight the container view of the current selection. So it you have an NSTextField within an NSBox, and you select the text field, the box will be highlighted. It's purpose is to dim out everything outside the scope that you can currently make constraints in.
You can see that it's a dimming down of everything outside the box, as if nothing is selected, the whole IB view port is displayed in the lighter shade.
The bug is that when you make a selection, IB clips the area of the container view to what's currently visible, and then adds this highlight as a rounded box 8 pixels larger. But when you scroll or resize the IB viewport, this clipped area isn't updated. So the rounded highlight box is seen to not cover the whole of the container view, just a clipped part (plus 8 pixels) of it.
Related
To keep things simple, let's say I have a window containing a single view, which has auto layout constraints binding all 4 sides to the window container view with offset 0. And assume that this view also has a constraint setting its aspect ratio to a constant value. If I resize the window manually, then then window nicely maintains the desired aspect ratio. But if I click the little green zoom widget, then the window fills up the whole screen, regardless of the aspect ratio, with part of the view being above the top of the screen. Is there some way I can make zooming resize the window as big as it can be, without violating auto layout constraints?
I couldn't very well detect this problem in the delegate method windowWillResize:toSize:, because that doesn't tell me which screen it's thinking about putting the window on. I could try to fix the window size in the windowDidResize: delegate method, at which time I do know what screen it's on, but I'm not sure exactly how to do that without reinventing Auto Layout's wheel.
Apparently someone thinks I wasn't explicit enough, so I'll try again. Steps to reproduce:
In Xcode, create a new macOS App project using XIB interface.
Open MainMenu.xib and select the window.
Reshape the window to be approximately square.
Using the Attribute Inspector, set the Full Screen behavior for the window to Auxiliary Window.
Drag an Image View from the library and drop it in the window.
In the Attributes Inspector, set the image view to show the NSComputer image and scale axes independently.
Expand the image view to fill up the window content area.
With the image view selected, click the button to add new layout constraints.
Add 5 constraints, binding the 4 sides to the container, and setting the aspect ratio. (see screen shot)
Build and Run.
Observe that if you resize the window by dragging an edge or corner, the aspect ratio remains fixed.
Click the green zoom widget in the title bar of the window, and observe that the window expands without regard for the aspect ratio constraint, cutting off part of the image.
I just set up a test project exactly as you specified, and when I invoke the window zoom widget, the window expands and retains its aspect ratio i.e. it works as expected. The only thing I can think of that might be causing your issue: maybe your content hugging and content compression resistance priorities are at odds with your constraints? Mind you, I just left them at the default values and it worked fine. Unfortunately Mac/AppKit development (esp. when using IB) is rife with these kind of odd bugs and weird behaviour, probably because Apple has not given it any love in years, so bugs creep in/fester and they are clearly so DONE with developing UI the 'old fashioned way'. (Using SwiftUI to make a Mac app is just as frustrating, in different ways, so I'll stick with what I know). FYI, I used Xcode 13.4.1 to create this test project. Good luck!
Question: Can someone identify why I am getting the extra grey area shown in my add item (top screen in screenshot) and how to eliminate it?
I have tried manually setting the size of the background object, removing and re adding constraints, clicking all the Xcode generated solutions for handling the autolayout errors shown below, setting the presentation setting to full size ala this answer all to no avail; it refuses to be consistent with the main menu screen (bottom)
Context:
Running Xcode 11...I have two scenes in a generic barcoding app, the main menu and the add item scene, and I am designing with iPad's in mind. With the size class for ipad pro 9 (wR hR) and set to landscape orientation, my add item scene has a huge amount of gray area bordering the visible content, unlike the main scene (though there is also a little grey area in portrait)
Figured out what was causing my problem; was using the wrong form of segue between screens, per this answer, in my case, a modal segue when I should have just been doing a show segue. Deleting and adding show segues with the presentation set to Full Screen in the destination views Attributes inspector did the trick.
(I found several similar questions, but nothing quite the same. Some were older than the OS in question. Some were doing crazy things, like completely custom windows. Nobody I found has instructions for how to make a perfectly ordinary window work correctly.)
Starting in OS X Lion, standard windows have had rounded corners. Unfortunately, I'm having trouble replicating this in my application. When an NSView is pushed against the corner of an NSWindow, sometimes it stays clipped to the round NSWindow, and sometimes it escapes and makes a square corner.
I haven't been able to figure out a pattern yet.
Even NSViews that "draw their background" sometimes force square corners, so it's not that.
My custom NSViews make square corners (am I responsible for checking my position in the NSWindow, and clipping to that, if I'm near the edge?), but some standard Cocoa controls do this, too.
For example, make a new Cocoa project, put a (scrolling) NSTableView or NSTextView in the main NSWindow, and add layout constraints so it follows the edges of the window. The bottom corners are square! The Finder, in contrast, has (what looks like) an NSTableView, right up against the bottom corner of the window, and it's rounded.
How do I make an ordinary NSWindow, with the proper round corners on the bottom?
The flag to set, in order to get NSWindow to clip its contents to its actual window border (why the heck isn't this the default?) is NSView's wantsLayer.
In code: contentView!.wantsLayer = true, when the window is loaded.
Or in IB: select the root View of your Window, and then in "View Effects inspector", check the box next to it in "Core Animation Layer" (even if you're not using Core Animation).
Meta: the documentation for wantsLayer talks about a lot of complex things that don't seem at all related to window shape or clipping, and it's not even a property of NSWindow, while NSWindow has some flags that claim to be about window corner rounding but which don't work any more, so I'm not sure how anybody is supposed to discover this, except by spending 2 days on trial-and-error. I hope this answer helps somebody else!
After much reading and experimenting, I still cannot get a simple TextView to resize fully in the horizontal direction using Xcode 5.0.2 in Mavericks. It resizes partially as the window is resized, then stops with long lines wrapped around even though my containing NSScrollView continues to resize as expected (it has four default constraints and no horizontal scroller).
Can anyone point me to a simple code/IB+AutoLayout example, preferably just a window containing just an NSTextView dragged in from the IB template library --- one that works? The Apple TextEdit sample code is almost irrelevant for this purpose although it does resize horizontally quite well. Also, there is the clip view for which I can find little information.
Any other tips appreciated.
Thanks.
Answering my own question:
Turns out that my problem had nothing to do with AutoLayout and little to do with NSTextView. It was the textfile I was using to test my code! This file was composed of records with tab-delimited fields.
Turns out that NSTextView comes with a default NSParagraphStyle with predefined tab stops that end at character 56 whereas my test file had tabs beyond that. Therefore, my lines wrapped around at the last defined tab no matter how much I stretched the window.
After changing my search terms, I found what I needed at the following links:
Premature line wrapping in NSTextView when tabs are used
How to have unlimited tab stops in a NSTextView with disabled text wrap
Apologies for wasting bandwidth.
Not sure why such a simple thing does not work in your case, but nevertheless here's what I did in Xcode to get an NSTextView follow window resize:
Create a new project (not document based in my case but it doesn't really make a difference)
Drag a NSTextView from the palette to your window. Align all four edges with the window edges.
Open the "Add constraints" pop-up (second button from the segmented control on the bottom-right part of your IB view.
Each of the four spacing constraints should show a number equal to the distance of your text view from the container window. If you aligned them, this number should be either 0 or -1. Click the down arrow for each of them and select "Use Current Canvas Value". Do it for all four. Make sure no other constraints are selected.
Click on "Add constraints" on the bottom of the panel.
Run your project. Your textview should resize with the window.
Also, as Jay's comment mentions, make sure you do not have any "leftover" constraints in your view. You can check this either by observing Xcode's warnings, or manually by inspecting your view's constraints by going to the Size Inspector tab (4th tab on the Utilities bar).
If you need to have your textview arranged in a more complex layout, it might be worth taking a look at the AutoLayout Guide.
I'm trying to learn auto layout so I can set up a moderately complicated display the way I want. I'm starting with a simple version. At least I thought it was simple.
I have a content view containing a NSScrollView, and a zoom slider. The scroll view is, of course, just a window into a larger 'canvas' on which the user can do things.
I'd like the scroll view to be as big as the window allows, with the slider underneath.
I've tried many things none of which work, in some cases when I resize the window smaller, the scroll view goes on up over the window's top bar, obscuring the title and the red yellow, green, dots.. this is just a grumble, I won't attempt to describe how I got it.
I'm working with Visual Format Language.
The immediate problem: I can only get the thing to work at all if I put in a hard size constraint on the scroll view.
I've got constraints like #"V:|[ScrollView]-[ZoomSlider(==35)]-| and
#"|-20#1000-[ScrollView]-|"
With these, nothing shows at all, until I put a hard size on the scroll view:
For example, #"V:[ScrollView(>=70#20)]" and #"[ScrollView(>=140#20)]" results in a little tiny scroll view (as expected) just above the slider.
Window is resizable, all right.
Is there a simple way to make the scroll view resize to occupy the most space possible when I resize the window? The only way I can think of off hand is to produce metrics for the scroll view based on window size, and use a notification to change the constraints when the window size changes. There should be something simpler!
THanks.ee
OOps. Thought I knew the answer until I started to write it.
AT least here is a partial explanation of things that were causing me problems.
You can't add constraints that position or size the Window's content view. But apparently you can mess them up by deleting them programatically. Some of my problems were solved by getting rid of
[self.myContentView setTranslatesAutoresizingMaskIntoConstraints:NO];
and
[self.myContentView removeConstraints:self.myContentView.constraints];
This left me with a lot of conflicting constraints. I fixed this be eliminating all content window constraints that I could in IB, then by marking the rest as placeholders.
I've got a ways to go before I understand how to use auto layout, but doing it in code is easier (for me) than doing it with IB