I was creating a simple GUI for an app, and came across this seemingly unusual behaviour when running.
Here is what my xib file looks like:
And here is what happens when I run the app:
I have tried creating a new view and using that instead, but it displays the same behaviour.
Why is the window getting resized? And more importantly, how can you prevent it from happening?
Thanks!
I've had this problem lately with Xcode's auto-layout feature. I solved it by manually deleting all the constraints and using the "Editor->Resolve Auto-Layout Issues->Reset to Suggested Constraints in Window.
You either need to use Auto Layout Constraints or Springs and Struts (old style ) to configure your views. The window normally will adjust itself as needed with auto layout.
With old style you have to manage the window frame or at least its content view frame.
Go to .xib file
and select size inspector. and from that set autosizing according to your rquirement.
Feel free to contact.
Increase main window width and hight.
Related
My application has a log window that displays lines in an NSTableView:
When I add auto layout constraints to the window no matter what I do I get a Misplaced View warning for the Clip View:
I've tried updating its frame, updating its constraints, and resetting to suggested constraints, but nothing gets rid of the warning. The window displays and resizes correctly at runtime, and it doesn't even appear to be possible to add constraints to the Clip View itself.
I've pushed the code to github if you want to look at it in Xcode: https://github.com/MagerValp/AutoDMG/tree/e57b0140e3fc3f7f9e0d4550341ed249a6cf5378. The code requires the 10.10 SDK to compile, but the xib should be viewable in Xcode 5 and up.
I met the same issue recently, warning about Clip view expected value is 17px larger than actual value.
I believe it is a bug of Xcode. And I do find a workaround to fix it(other than downgrading my OS to 10.9).
The solution is to edit the attributes of tableView in IB, disable "Headers". Don't show table headers and the warning will be magically gone. And we can guess that by default the table header is 17px :)
It's just a workaround, not an ideal solution. This is not our fault. The best solution is to wait for Apple to fix this Xcode bug.
Scrollviews' subview hierarchy are only sort of compatible with auto layout.
One way around this is to constrain the clip view so it is not bothering you.
Then in the inspector, mark those constraints to be removed at runtime.
ScrollCiew
ClipCiew
TableView
If the error is coming from ClipView.
Check the ScrollView size, remember it.
And then click ScrollView as target, open up size inspector, enable Intrinsic Size using Placeholder with ScrollView size.
I use the Xcode 12.3, the latest version of Xcode. But also have the same warning. I remove the misplaced view warning by change the TableView Content Mode from View Based to Cell Based and then the warning disappeared. And then I change back to View Based. The warning will never appeared again.
When I try to place objects using the Interface Builder in Xcode into a NSScrollView, they appear fine until runtime in the application, where they do not appear at all for some reason. I want it to be so that I can place multiple buttons and labels in the view, and have the user be able to scroll down to see more.
Am I not meant to use NSScrollView for this purpose?
Is there another way to go about implementing it I am not aware of?
You need to check the where you added the UI objects.
You need to consider these :
Is your autolayout enabled?
Did you flipped the view?
Resizing mask is working good as per your requirement.
Am I not meant to use NSScrollView for this purpose?
No, you picked the correct control for the requirement. NSScrollView is indeed for same kind of use.
I'm making a document viewer in Objective-C, I want to have a bar at the top of the page with a bunch of buttons in it which open up menus, change pages, etc. At the moment I'm using a custom view which then just has all of the buttons inside it, but my problem is that it isn't a static vertical height, so when the window resizes it changes the size of the custom view rather than my PDFView. Is there a way I can stop it from resizing, or is there a better method I should be using to create a menu?
Thanks!
With auto layout, you can just give the view a fixed height -- from the editor menu, choose Pin, then Height. Make sure that it then only has one vertical constraint, either to the top, bottom, or centerY.
Are you using Auto-layout ? You may have to play with it.
Without seeing the code it's hard to debug the problem. Post the snippet where you're re-sizing the views if you're not using auto-layout.
The question may be similar with
Designing inside a scrollview in xcode 4.2 with storyboards
but none of the answer there makes sense at all.
Okay I created a new controller and I added a scrollView.
The very first thing I noticed is there is NOWHERE to specify the content size of the scrollView.
Not in attributes inspector, not in size inspector.
Then what?
I am expecting some larger than normal box where I can draw all the view I want to put in. There is no such thing either.
I am very frustated.
All the "tutorial" out there tell about how to fill scrollView using code.
Another thing I tried is to select controller go to size inspector and then choose FREEFORM.
Great. I still can't make that template big.
Should I do this in XIB instead? At least on that one I can have one huge UIView. Or what is the official way industry standard way of doing this? Is there a WWDC for this one?
Say I want to draw something like these:
I don't think you can get a tutorial on this as it is simply impossible in IB. As most people already commented out what you want to do here need to be done programmatically.
If you are using XIB you can set up all your content there. Under the size tab (in the inspector) you will need to change the height to fill all your content but you still need to set up your contentSize programmatically.
For storyboard I don't think it is possible to change the size of your scrollview in IB.
I've created an application for Mac that uses a horizontal resize view (technically a BWToolkit resize view) that is linked to a toggleCollapse button. After collapsing and expanding the panel a few times, this happens (see image) right table-view should be flush with panel divider. Any one have any info on why this is happening. I've carefully adjusted my alignment and anchors to be correct but it seems like this is a weird issue that bugs out the view?
EDIT: Is anyone NOT having this issue? Any input would be helpful! Maybe I just need to start fresh?
This is a known bug in BWSplitView itself, and is related to how view animation and timers interact in that view. The details are covered here:
http://bwalkin.lighthouseapp.com/projects/36323/tickets/34-split-view-doesnt-resize-subview-properly-during-a-toggle-uncollapse-after-manual-collapse
Basically, before the view is animated, autoresizesSubviews is unset, so that the view can be collapsed/expanded without affecting the contents; a timer is then scheduled to restore the autoresizesSubviews property for when the animation has completed. But (of course) the animation may sometimes finish ever so slightly earlier, or later, than the scheduled timer fires; so autoresizing is switched on before the animation has completed, resulting in a few pixels resize. As you've probably seen, the subviews tend to move around a bit as the view is collapsed and uncollapsed.
The "full" fix for this would be to restore autoresizing when the CAAnimation has completed using a callback, but this hasn't been implemented yet. However, in that thread "Robert Payne" has posted a version of BWSplitView.m which uses a slightly different approach - the view sizes are recorded before collapsing, and restored after expanding. I applied this patch myself (I think it won't compile at first - but it's a simple matter of an undeclared variable?) and can confirm it does fix the problem.
Let me know if you'd like a BWSplitView.m which compiles successfully, or a copy of the compiled framework.