I have a Window and a WrappingTextField.
I want the WrappingTextField to always fill the entire Window. Even when the user is resizing the Window, and when it is in full screen.
No matter which options or constraints I choose in Auto Layout, it only resizes with the Window horizontally, but its height remains the same, even if the height of the Window grows.
How do I make it fill the entire Window, and stay that way?
By WrappingTextField I'm assuming you mean an a standard NSTextField object with it's Layout set to Wraps within Interface Builder.
The resizing behaviour of an NSTextField is influenced by its Content Hugging Priority. By default Interface Builder sets this at 750 for the control's Vertical dimension, and this is probably what's preventing your text field from resizing the way you want it to. Give it a smaller value - like say 100 - and the problem should resolve.
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!
Say, I have a CListCtrl-derived control. I want it to be always square (i.e. it's width and height should be always equal to each other).
The control resides on a dialog (CDialog-based), it is resized once the dialog is resized (the control is resized using SetWindowPos()). What I want to achieve is to make it impossible to resize the control improperly: the control must always have equal horizontal and vertical dimensions regardless of what is passed to SetWindowPos.
Of course, I can control the values that are passed to SetWindowPos. The question is: is it possible to control the size of the CListCtrl-derived control inside the code of that control itself?
If you subclass the control and have it handle the WM_SIZING message you can constrain the resize in any way you'd like. Just modify the RECT structure that's passed with the message.
I am trying to change the size of the UI Elements within a UWP Window on the change of the size of the window itself, such as clicking the edge of the window and dragging right. However, on increase of size, there seems to be Bounds set on the creation of the Window for the maximum size of the content, is there anyway to bypass this Bounds?
Try setting the UI Element's HorizontalAlignment and/or VerticalAlignment to "Stretch". Alternatively, if you want to scale it too, you may put the whole thing in a ViewBox. There are really quite a few options to achieve what you want.
I have a window I'm setting up with auto layout. There is a view in the middle of the window that contains three controls, and I would like the window to refuse to resize horizontally smaller than the intrinsic size of those three controls.
The outer buttons both have horizontal space constraints to "stick" them to the outside of their superview, and the checkbox in the middle has a horizontal space constraint sticking it to the left side of the "Sync text" button. There is also a >= constraint between the "Sync outline" button and the checkbox, to make sure they don't overlap, but the checkbox prefers to hang to the right. All these constraints have a priority of 1000. The window itself has no minimum size specified.
When I use the "Simulate Document" command in Xcode, everything works as I'd expect, and the window won't let you size it smaller than in the screenshot above. However, when I run my application, the window does allow resizing smaller than that width, so that the buttons start to shrink and eventually the controls overlap each other. I'm not implementing any of the size related window delegate methods, so I don't see any place in the app's code where it might be influencing the resizing.
Any ideas on what could be causing this difference in behavior?
OK, I finally figured out what the heck was going on here. It turns out the problem was that I was implementing the -splitView:constraintMinCoordinate:ofSubviewAt: delegate method (as well as the maxCoordinate one) to restrict the size of the split subviews in the vertical direction. Yes, restricting the vertical resizing of the split view affected the horizontal layout of the buttons.
It appears that what happens is that, if you implement those delegate methods, NSSplitView reverts back to using autoresizing masks to layout the subviews rather than auto layout constraints. Since the view containing those buttons is no longer participating in auto layout, the buttons smush together when you resize the window small. In the simulator, the split view doesn't have a delegate set, so all the auto layout stuff works fine in that environment. Note that merely having the methods implemented is enough to trigger this, even if they just return the proposed coordinates unchanged.
The solution ended up being quite easy, which was to delete the delegate methods and replace it with a vertical constraint on the subview to restrict its size instead.
When the OS X dock is shown, it "reserves" some screen area and prevents maximized windows from going behind the dock when maximized. How do I make my own Cocoa application do the same?
A window's "maximizable area" is based on the screen's visibleFrame.
[[NSScreen mainScreen] visibleFrame]
The returned rectangle is always based on the current user-interface settings and does not include the area currently occupied by the dock and menu bar.
Because it is based on the current user -interface settings, the returned rectangle can change between calls and should not be cached.
The rectangle defining the portion of the screen in which it is currently safe to draw your application content.
There is no mention of being able to adjust this visibleFrame rectangle, so I do not think you will have any success influencing the "global" Zoom size.
However, if you only want to adjust the Zoomed size of your app's window, return a smaller rectangle in the NSWindowDelegate method windowWillUseStandardFrame:defaultFrame:.
The standard frame for a window should supply the size and location that are “best” for the type of information shown in the window, taking into account the available display or displays. For example, the best width for a window that displays a word-processing document is the width of a page or the width of the display, whichever is smaller. The best height can be determined similarly. On return from this method, the zoom: method modifies the returned standard frame, if necessary, to fit on the current screen.
This will allow you to take into account a "docked sidebar" when Zooming your app's windows. Other apps will be resized on top of the docked sidebar.