Loving XCode 6/iOS8's new way (using size classes) of doing Autolayouting (despite it being a pretty hard puzzle to solve at times).
But how does one reset one of the size classes back to Any/Any?
Set you size class to wAny hAny
Now you should see constraints installed outside this size class as greyed out in the pane on the left:
Select this constraint in the list and in the detail inspector pane on the right you should see this:
Here you see I installed a wRegular hAny constraint.
Hit the little x to delete this constraint in this size class.
Repeat for any other constraints you have.
Once these constraints are no longer installed in any size classes you can select and delete them in the left pane.
When you click on the Width/Height, take your cursor to the middle square and select it. That will set it at Any/Any.
Edit: I think I may have misunderstood. If, for example, you are working in wCompact hRegular, and you don't want those changes anymore and you want it to "inherit" from Any/Any, then you'll have to go about either uninstalling or deleting the constraints you created specifically for that size class. When you have your view controller outline showing, and the constraints appearing, the ones not grayed out are active for that size class. Check each one to see if any are specific to the size class you're working in (such as wCompact hRegular).
You can also uninstall or delete any additional UI objects you added to that size class specifically.
Hope that helps.
Related
I'm worjìking on a testing project. All the project is in wAny hAny size class but I accidentally worked for some minutes in wRegular hCompact, now in wAny hAny there are elements that aren't present in wAny hAny which I refer to in the code, so the I get errors when running the project in simulator. How can I get rid of wRegular hCompact size class?
EDIT
Two screenshot of the current situation. There are not constrains but some elements are moved when switching from a size class to another.
You can see which constraints are associated with a view by selecting it and then selecting the Size Inspector button in the Utilities pane.
Double click on the constraint you want to inspect which will show you all the size classes a constraint is installed for. Click on the little X next to the size class that you wish to remove it from. In this case wC hR.
We try to use the treefilter in IcCube to show categories with subcategories. Now we discovered two problems, we don't know, how to fix:
We have 15 categories on level 1, but only the first 11 of them show. There is some space underneath, so it doesn't seem to be cut due to rendering:
We are not able to activate a vertical scrollbar, so when we unfold the tree, there are parts we cannot see anymore. The hotizontal scrollbar is there, but once the tree is too big (image 2) it can't be used anymore as well.
Did we do something wrong and there are options we didn't see, or are our problems due to some bugs in this widget?
Point 1)
Try to increase Max Member Count property on the Query Wizard tab of the widget (this number is for all the members to be managed, not only level 1 items)
Point 2)
Try adding {"cssStyle":"overflow:auto"} in the Content CSS property of the Box tab of the widget.
I am working on a specific size class layout of an xcode project and I hit a snag.
My constraints got very messed up and I want to restart the view.
Is there a way in the interface builder for me to reset a size class (e.g wAny hCompact) back to its any constraints settings? (i.e. back to how it was with wAny hAny)
This should really be an automatic process in Interface Builder, but as far as I know it is not so you have to do the dirty work.
The best solution I have found is a combination of using Interface Builder and the source editor for this task. Remember that there are two things to reset, both the auto-layout constraints as you are referring to, but also the variations you might have created. Lets start with auto-layout constraints, and deal with variations later:
Reseting auto-layout constraints
Find a constraint you want to reset. Choose the "Show Size Selector" panel in the utilities view. At the bottom you will see the size classes this constrain has been added to. If it is only installed on the size class you want to reset, you can delete the whole constraint, otherwise, just delete it from the size class you want to reset by clicking the cross.
Variations
I have only managed to reset variations using the source editor. Either use an external editor, or "Open As -> Source Code", and search for variation elements. Make sure the size class key is correct, and delete at will.
Found a quick fix for this.
In the Storyboard go to the file inspector tab, then, under "Interface Builder Document" Section, uncheck the "Use Size Classes" checkbox and it will ask you to keep either iPhone or iPad current layout.
After choosing it, you can check "Use Size Classes" again and the other size classes will reset to the one you chose before.
Note: All other size classes will reset to the chosen class!
Assume you've selected an object and you have the Size Selector in the Utilities panel open. You can see the list of constraints applied to the object. In the list of constraints you could click on the little gear and pick delete. You can't in Xcode 6.
There are still several ways to delete constraints in IB:
Find the constraint in the Document Outline and delete it that way (but it can be hard to find).
Click on the little bar in the storyboard and delete it that way (which can be hard to click on).
Double click on the constraint in the Size Selector which will open Attribute Inspector and highlight the constraint in the Document Outline. This can be a nuisance when you want to delete several.
Still, I miss ease of use of the gear delete feature and I'm wondering if it's still there in a similar fashion and I just can find it. While the other ways work, I find myself wasting lots of time especially when playing with the new Size Classes feature. So, find a easier way to delete them?
In Xcode6 (Beta5) when I click on a particular constraint in the Size inspector, it acquires a thin blue border. The constraint can then be deleted using the backspace.
The accepted answer is right, but there is so much frustration with selecting constraints that lay outside of selected view that I decided to add this tips as another answer.
I found incredible list of tips that helped me to solve this problem.
The problem:
You select the view and Xcode shows related constraints.
You try to choose the one that is outside of selected view.
You fail (end with selecting the view beneath the constraint)
Soulution:
Click it with Shift+Ctrl pressed and you'll see a menu of all the views that exist where you've clicked.
To delete selected constraint press delete key.
The selected answer is incomplete. When you delete the constraint from the Size Inspector, you are leaving behind the constraint object in the Document Outline pane. It is greyed out, meaning it is not used, but still exists and, what's worse, will affect auto layout with errors, warnings or conflicting constraints and you will go crazy until you also delete them from the Document Outline pane.
So:
1. Delete the constraint from the Size Inspector as in the accepted answer
2. Delete any greyed out constraints from the Document Outline
Live a happy, constraint-free life.
This answer from #wayne chi is the simplest, and spares you from hunting down constraints in Document Outline:
Double click the grayed out constraint (switches focus to the constraint) then press delete. This will delete the constraint.
Sometimes, the easiest way is to close the file in Xcode and edit it with a text editor. :-/
If you want to delete ALL constraints from a viewController simply turn off auto layout and then reenable it (or don't) and all of the constraints will be gone.
I'm running into a problem trying to anchor a textbox to a form on all 4 sides. I added a textbox to a form and set the Multiline property to True and the Anchor property to Left, Right, Up, and Down so that the textbox will expand and shrink with the form at run time. I also have a few other controls above and below the textbox.
The anchoring works correctly in Visual Studio 2005 (i.e. I can resize the form and have the controls expand and shrink as expected), but when I run the project, the bottom of the textbox is extended to the bottom of the form, behind the other controls that would normally appear beneath it. This problem occurs when the form loads, before any resizing is attempted. The anchoring of the textbox is correct for the top, left, and right sides; only the bottom is malfunctioning.
Has anybody heard of this and if so, were you able to find a solution?
Thanks!
UPDATE:
Here is some of the designer code as per Greg D's request (I am only including the stuff that had to do with the textbox itself, not the other controls):
Friend WithEvents txtRecommendationText1 As System.Windows.Forms.TextBox
<System.Diagnostics.DebuggerStepThrough()> _
Private Sub InitializeComponent()
Me.txtRecommendationText1 = New System.Windows.Forms.TextBox
' ...snip...
'txtRecommendationText1
Me.txtRecommendationText1.Anchor = CType((((System.Windows.Forms.AnchorStyles.Top Or System.Windows.Forms.AnchorStyles.Bottom) _
Or System.Windows.Forms.AnchorStyles.Left) _
Or System.Windows.Forms.AnchorStyles.Right), System.Windows.Forms.AnchorStyles)
Me.txtRecommendationText1.Location = New System.Drawing.Point(4, 127)
Me.txtRecommendationText1.Multiline = True
Me.txtRecommendationText1.Name = "txtRecommendationText1"
Me.txtRecommendationText1.Size = New System.Drawing.Size(223, 149)
Me.txtRecommendationText1.TabIndex = 10
End Sub
ANOTHER UPDATE:
The textbox I originally posted about was not inherited from a baseclass form (although it was added to a custom User Control class; I probably should have mentioned that earlier), but I recently ran into the same problem on a totally unrelated set of controls that were inherited from a baseclass form. It's easy to blame these problems on possible bugs in the .NET framework, but it's really starting to look that way to me.
Is your Form localized? Check the resource files for an entry with Textbox.Size, delete is and reset the size.
Is your Form inherited and is the Textbox on the baseform? Try setting the Textbox's access modifier to Protected or Public.
Have you implemented custom resize logic? Turn it off and see if the problem is still there.
Have you entered a Textbox.MinimumSize/MaximumSize? Remove or change the value.
It might also be a combination of these things...
Does the form snap back to the expected layout when you resize it after it's been initialized weirdly? Also, have you set a Height or MinimumHeight/MaximumHeight property for the text box?
If possible, a few snippets from the designer code might be useful. :)
One possibility that I've run into in the past is DPI. If you're running/testing your code on a machine with a different DPI setting than the machine that you're developing on, you may observe some strange things.
The anchor functionality essentially establishes a fixed distance between the edge of a control and the edge of the control's parent. Is your textbox embedded within another control (e.g., a panel) that doesn't have its anchors properly set? Right clicking on the text box in the designer should pop up a menu that lets you select any controls that exist underneath it, also.
Does your program include any custom resize logic, or does it modify the size of the textbox programmatically outside of designer-generated code? That might also result in weird behavior. I've assumed maintenance for a number of pieces of software at my organization where the original developers spent a great deal of time implementing (buggy) resize logic that I had to tear out so that I could just let the designer-generated code do the work for me.
The textbox I originally posted about was not inherited from a baseclass form (although it was added to a custom User Control class; I probably should have mentioned that earlier), but I recently ran into the same problem on a totally unrelated set of controls that were inherited from a baseclass form. It's easy to blame these problems on possible bugs in the .NET framework, but it's really starting to look that way to me.
It's very likely because of the 'AutoScaleMode' property being set in InitializeComponent(). Try setting it to 'None' and see if that fixes it. I've had these problem a couple of times now.