First of all, I must mention I have duplicated the constraints in a new project and have not been able to duplicate the problem. The problem occurs in a complicated storyboard project I've been working on for months.
For simplicity's sake, this is basically the issue:
I have a Container View inside of the default View inside of a View Controller. The Container View has constraints to the Top, Bottom and Trailing edges of it's superview. I have two "equal widths" constraints connected between the superview and container view. One is equal to the superview, the other is proportional to the superview with a 0.9 multiplier in the constraint.
I have a button superimposed on top of the container view which alternates between the 2 "equal/proportional widths" being active (I've currently deleted all the other objects in the View Controller for simplicity, to try to isolate what is causing the problem...
When the button switches the "equal widths" constraint to the 0.9 proportional width constraint, it "pushes" the container view away from the trailing margin (by 12 points), while it also shrinks the container view by 10%, as desired.
I've been working on this for hours, so far to no avail... out of desperation, I added an extra trailing edge constraint to switch on and off, with an extra 12 points to compensate for the shift when the proportional width is switched on. The default trailing (to superview) constraint is set at -20, as I increased it to -30, -31, -31.5 it got closer and closer to looking right, but when I put it's constant at -32, it jumped again, about 12 to 20 point, off the edge of the trailing margin! I know this is not a good way to try to solve this problem, but I wanted to mention it, in case it may be a clue for someone more knowledgable than me as to what is causing the problem..
Thank you for any help you can offer!
UPDATE:
The problem seems to be stemming from a conflict in the VC embedded in the container view. The Height of the embedded VC was 720, while it's container was 720... but even after I change these Heights to match, either way, I get the same problem...
The problem seems to disappear if I delete the embedded VC and just use the container view, but this is not a solution since I need the content of the embedded VC...
One last note, I have a similar method in place with a button press which changes the height of the embedded VC, but with no problem..
I have experience similar constraints problem before, without seeing the storyboard I cannot pin point the exact cause but you can try the following:
Double check your constraints are connected to your codes, even if they are not the codes will compile and run but with no effect.
Look out for logs of auto layout breaking constraints, there might exist another constraint that held your view in place cause the newly activated one to be broken.
If both are not the cause, also check if the button is calling the right action.
In any case, if my tips did not help at all, you might need to provide more information or a screen cap showing the view and it's constraints for a better understanding of your problem from my end.
I solved it!
So, as I suspected in my update, the problem stemmed from something not syncing up in the constraints between the container view and it's embedded view controller. In the container view, as mentioned above, there was a constraint for the trailing edge of the superview and 2 for the width I was switching between with a button. The embedded view controller's view was had a leading constraint to it's superview. Once I deleted that and switched it for a trailing view as well, the problem was solved!
Lesson learned: If you are going to alter a container view with multiple width or height constraints, make sure have the same side constraint in the container view and the embedded view's contents (top or bottom for y-axis, leading or trailing for x-axis).
Related
I can share the code if needed but it felt like a lot to share to start, so I'll try to explain narratively. I am creating an interface to display network data (as you might have guessed from the title). My first issue has been going on for a few days where visIgraphLayout is not laying out my visual correctly. Regardless of using "full" or "square" as the "type", the network map extends beyond the edge of the display space. When I resize the interface window, then the map will snap to full. Why won't it simply resize automatically? If it matters, I do have the output space in a box element. Also, I have the layout styles working off radiobuttons, and when I switch between styles the map goes beyond the edges again.
Part 2 begins. While the above problem is annoying, it was livable. However, a new wrinkle popped up. I added some font size control to my visNodes code - i.e., radiobuttons set to switch between off (0), small (5), standard (14), and large (40) font size options. Once I implemented this code, when I resize the interface window, now the network map disappears completely after initial load. If I select a new label option, it will redraw but beyond the edges of the space.
All the issues resolve themselves if I ditch the visIgraphLayout, but then I lose the layout functionality which I really like.
I hope this is clear enough. I really appreciate any insights the community might provide. Be well.
I think I have figured out an answer. Long story short, certain pieces didn't work and play well with others. Went through and build it again, and all it good.
Cheers.
This has me stumped. I have a view with two child labels as shown here...
Here are the constraints for the entire view:
All of those constraints have a weight of 1000.
The problem is the orange label has it's horizontal ContentHugging set to 1000 whereas the blue label has its horizontal ContentHugging set to 250, which, AFAIT means the orange label should hug its content causing the blue label to expand to fill the area thanks to the constraint between them with a length of zero. Yet I'm seeing the exact opposite. What gives?
Settings for the orange label
Settings for the blue label
So what the heck am I missing?!
Update
After further research, this seems to be either a corrupted NIB file, or an issue with Interface Builder itself. I say this because I created a second NIB with the exact same settings as above, but this time it worked as expected. (I even copied the views themselves from one to the other.)
To be sure, I went through everything view-by-view and compared all values and constraints and it all looked completely identical.
While I could open up the nib itself and compare the raw text to see if there was something odd, since the new one works, I'm considering this as an anomaly, meaning unless someone can point out a mistake made above that I'm still not seeing, I will close this out as such.
I am building this form: http://codepen.io/anon/pen/gFoIG/
and so far I am satisfied. Unfortunately I have some issue that I seem not able to fix.
First of all, I want to enforce the label positions beside their respective inputs. Now the form breaks down easily (with the opera emulator for smartphone and tablet, the privacy label goes below the check, but I want that it stays beside it)
The other issue that I have is that I want it to fall back gracefully when there are small screens, like placing the second image below the first and placing the input controls one below the other and take the full screen width to be bigger and easier to interact with, but so far I only was able to break the layout with my tests.
This issue: the the form layout breaks, the internal control (input, button, etc) go outside the container div. How do I enforce the container to keep everything inside? I've experimented with blocks, floats and whatever, but if the layout breaks, the input boxes usually go outside the gray rectangle.
Last issue: If I insert this form inside an existing website (for example, a page in wordpress) the layout get completely destroyed because influences from the theme style. How do I enforce my style on my form, keeping it isolated from the other styles? I can think of the iframe as a solution, but it is the only one? It is a good practice?
Anyone can help me with that?
You might want to take a look here. Its a site I just set up to explain an approach to responsive using a jQuery plugin to manage redoing layout. I think it could work for your example quite easily. Also because it can target a container div at any depth in a web page, it could be helpful in the scenario where the layout you want to reflow is inside a 3rd party container (as long as you can run script on the page).
I'm setting up a UIRefreshControl in my uitableviewcontroller, but there is a big gap between the navbar and the top of the uitableview. Playing with 'adjust scroll view insets' doesn't help, as the controller will underlay the navbar at startup. I could disable 'under top bars', but I want that ability when scrolling. When poking around in the debugger, I noticed at various times the tableView.contentInset is offset by 82 points, which is different from the ususal 20/64 pt offset people talk about regarding the new ios7 bar behavior. What's going on here?
Found a solution while poking around more; hope it saves someone a few hours!
I needed to instantiate my UIRefreshControl after viewDidLoad:, or avoid setting its attributedTitle in code at least until after that (e.g. if I enabled refreshing of the table in IB). Setting the string inside viewDidLoad: messes up iOS's layout of the control+tableview, but it's ok within viewWillAppear: or later once the geometry is set. And I think 82 points is the height of the UIRefreshControl. Setting the refresh title in IB would've also avoided this problem, except that I was doing so in code because I didn't want to have to enable refreshing in IB all the time with each of my tables.
Having recently switched to autolayout in Xcode 5 (and having watched the developer video from WWDC 13), I'm finding things to work pretty well with the exception of a View-Based NSOutlineView.
Before autolayout, this worked. Everything works fine and is in the right location, but now, specifically when I scroll, some of the new entries (and not all of them) end up in the wrong place, always larger and slightly higher.
The problem goes away once they are redrawn, but I don't understand the mechanic for drawing these NSTableCellViews and when they are created by the Outline View. I mean, it looks like they are created at some point, the program is guessing about the proper constraints, and then fixing them after a redraw.
It would be really nice to post an image to explain this, but can someone explain the life cycle of a view in an NSTableView or NSOutlineView?
I had to grapple with that issue myself and I was able to fix it today. This will happen if you are using any content inside an NSTableCellView that needs to be resized to fit into its cell or any subview of it. I fixed this problem by using an NSImage with the exact same size as a placeholder NSImage I added as subview to the NSTableCellView on IB. This resizing will break the constraints you added to or expect in this view.