I can't see items that add to my ViewController before like buttons but it shows in simulator and I tried to Select Identity Inspector of view and set Lock to Nothing but does not changing , How can I solve that ?
This quote from another post by matt could be helpful:
"It looks to me like you are using size class and you went into a particular size class and added these views. Now you are back in Any size class, so the views are not there (that is why they are greyed out in the document outline at the left). They are available only for that particular size class. If you switch back to it again, whatever it was, you will see them again. Basically, you have created conditional views - the condition being that they are present only when that particular size class situation is the case.
In other words, if you want your layout to apply in the general case, you want to start by creating and editing it under Any size classes. Only then do you switch to a particular size class and modify the layout for that particular size class.
when i run my app all ui element visible in my device
Yes, because on your device the particular size class situation matches the size class you were editing when you added those views. So there they are. That seems to me to prove my guess is right."
link is: why storyboard ui elements not showing on UIViewController in xcode 6?
Related
Recently, I encountered a problem with the Interface Builder which I failed to solve. I'm using a UICollectionViewController and whenever I add a Cell it immediately shows a orange rectangle (indicating a auto-layout update). Updating the frame/cell doesn't change anything. The warning associated with the orange marking reads "Expected: height=Y, Actual: height=X" where Y is always exactly X-100. That is: When I set a custom cell height of 193, it says "Expected: height=93". This happens no matter which size I enter.
The problem with this is that I have many difficulties with the subviews and their constraints. For instance, if I add a subview with the constraint to keep the same height as the cell, it will be shown as 93 (the expected height), even though my cell should be 193. Layouting becomes impossible.
I tried adding a new cell, same issue. I tried removing every subview and re-adding them, nothing.
Any ideas are highly welcome.
Thank you very much!
Solution found ! (Xcode 9.2)
The bug seems to only happen when you try to embed the UICollectionViewController in a Container View in the storyboard. The workaround is to remove the segue while you set your constraints, and re-add the segue once your constraints are well set.
I also think that setting UICollectionViewController size as Freeform could be responsible of the bug. If so, try to set constraints before changing the size.
Hope this helps !
I'm not sure if this solved it, but the warning and issue disappeared once I did the following:
Select the CollectionViewController in Interface Builder and set the size to freeform and make the height larger, large enough to show all your template cells. (Plus: maybe refresh the views). That solved the issue for me.
In my case, I have added two collection view cell, withing collection view Controller.Only setting the view controller to free form wont help us. Need to update the size, to get rid of the warning.
updating collection view cell frames, wont help us. Warning will be continuously changing its length.
I tried to work without considering the warning, as I have set my collection view cell size programmatically and it does working as expected.
I think it's just a strange bug
I delete the collectionViewController in SB, then create a new one, the problem disappear
This is a common bug with Interface Builder. I don't know the exact cause, but I believe it's something to do with placing collection views inside arrangement views that do not have an exact size. I've seen it when putting them in scroll views, stack views and container views.
There is a simple fix, although I believe this to be a bug in IB that ought to be corrected by Apple rather than hacking around it. The solution (for me at least - your mileage may vary!) is to place the collection view inside an ordinary UIView and pin its edges to it, then place that parent view in the position that you wanted your collection view with all the constraints it required.
I usually found that there were actually no auto layout issues at run-time, which is why I believe this to be purely an Interface Builder bug.
I have a window with a programmatically created toolbar, which is populated with an NSToolbarItem that has a custom view defined in a xib file. If I check "Translate Masks into Contraints" for the view, then it doesn't resize itself correctly, so its content gets squashed even though I set its compression resistance priority to 750. If I uncheck that on the other hand, then I get a "Detected missing constraints" error at runtime. Also, the content of my view then resizes itself correctly, but it ends up clipped like so:
So it looks like the toolbar sticks my view into a container view and, in order to get the correct behaviour, I should set up layout constraints that allow my view to position itself correctly. However, I don't see how to access that container view... Any idea what I am doing wrong?
I am probably missing something obvious since one would think that this is a very standard setup, but Google didn't come up with anything.
Answering my own question, I opened a support request with Apple, the outcome of which is that this is now being treated as a bug by Apple.
In case anyone else runs into this, a good workaround is to create an intermediate view which contains the toolbar view as a subview with constraints #"H:|[toolbarView]" and #"V:|[toolbarView]", has translatesAutoresizingMaskIntoConstraints=YES and to use this view as the toolbar item. It then suffices to listen for size change notifications of toolbarView and to adjust the size of its superview accordingly.
I'm trying to get the split view controller working properly but apparently there's a bug in there or I'm missing something.
First of all, I've started a blank OSX Obj-C application, and in the Storyboard I've dragged the split view controller. Next, I've linked the segues from the main window controller to the split view and added two labels.
http://i.imgur.com/dlFObaF.png
When I build the project, it shows only the second page. Not to mention strange window size in the final build.
http://i.stack.imgur.com/IqRqr.png
I've tried everything.
This occurs in both vertical and horizontal split view.
Any suggestions?
I had the same issue myself today, but it's just the split line wasn't initiated properly.
To see, this, once you run your app, move your mouse toward the edge of the window and drag it, you will now see another view emerging.
To my best knowledge, I do not know how to fix this in IB or in code. Apparently NSSplitViewController does not have a property like UISplitViewControllerAutomaticDimension. Would appreciate if someone can contribute to this.
Edited: Found an answer via another thread. Basically, try to add some constraints to the subviews inside each view and that should prevent the size of a view to be zero. In my toy example, adding margin constraints to my buttons worked out well.
Whenever I get a conflict in a storyboard file, I can usually resolve it. However, I have an issue that has now come up twice in two weeks.
At the very bottom of my Storyboard file, I see block named "inferredMetricsTieBreakers", with bunch of "segue" tags contained within. It seems that some segue in my local repo is conflicted with another segue in the remote repo. To be safe, I could just "choose both". But since this happened once before, I'm afraid that it will keep happening, and eventually have a long list of these segue references at the end of my storyboard file.
Just wondering if anyone is that intimately knowledgeable about these tags in the file, or whether I should just blindly continue to just "choose both" and ignore the issue.
Thanks,
-Dan.
Each view controller in a storyboard has "Simulated Metrics" which you can see in the attributes inspector:
Some of these metrics are inferred (thus, inferred metrics).
As mentioned by #thesystem, if a given view controller is the destination of multiple segues, there could be differences between the simulated metrics of the source view controllers of the segues. To address these differences IB picks a segue to break the tie when resolving the inferred metrics for the destination view controller.
#rick-pastoor's conclusion that it's safe to remove the entire inferredMetricsTieBreakers section is correct in that IB can just choose different tie-breaking segues. However, there is no guarantee that the new tie-breakers will lead to the same layout results in IB.*
For example, I had a situation in which, depending on the tie-breaking segue, a view controller was shown in IB either with or without a status bar. Its view maintained a height of 568pts in both cases, such that the position of the top layout guide kept changing. This snowballed into other undesired (and largely meaningless) changes to the frames of views constrained to the top layout guide.
Based on these observations, choosing both the new and old sets of inferred metrics is not advisable. Instead, remove both sets and then open the storyboard in IB to allow the ties to be broken before committing the merge. To avoid undesired frame changes due to a change in tie-breaking segue, pick some value other than "Inferred" for the relevant simulated metrics of the destination view controller. This will ensure that IB generates a consistent layout result.
* The results at runtime should be the same unless there is any logic that relies on the initial layout immediately after the view is unarchived.
Same thing going on here. Got errors in my storyboard file after using your "choose both" method. Found that searching the storyboard for the segue references resulted in one segue that was mentioned inside the inferredMetricsTieBreakers section. Removing the segue from the list solved my breaking build.
To try and find out what this inferredMetricsTieBreakers does, I tried removing the whole section first. Breaking my build. Next I removed all the items. During the build, Xcode added 2 new and different segues to my list (before the merge I had 3). The application I'm building is working fine.
My conclusion: it's safe to remove all the items and perform a clean build. This will keep your storyboard clean.
It looks like, the tie breakers occur when in the storyboard one view controller is connected from two or more other view controllers via segues and its simulated metrics setting is set to "inferred" but Xcode cannot make sure that inferred means exactly one metrics setting (landscape or portrait) in every case.
I fixed it by changing all controllers simulated metrics to "inferred" and all metrics are inferred from a controller that has fixed simulated metrics setting "landscape". After that I removed the tie breaker segue ids from the section (but not the section itself).
Changed the metrics from Inferred to Freeform (Xcode 8, Swift 3). Solved my problem.
I’ve been reading through several books on Mac development, but cannot find the information I’m looking for.
The books all describe how to make floating windows or panes, but never mention how to make them all in one window. A simplified example of what I’m looking to create is shown below:
Basically, there will be three windows; A selector window with radio buttons to choose which NSDocument is currently being used, a window underneath that with buttons that show different windows to the right that allow viewing and manipulation of certain data.
For a example, each NSDocument may have a color value that can be set in the window shown by clicking view A, and some text strings that can be set in the window shown by clicking view B.
So the questions are:
Is it appropriate to use a single NSDocument sub-class for each Doc #1 and Doc #2?
Which classes should I use to set up the application as shown? NSWindowController? NSWindow? NSPanel?
I’m only looking for guidance on what to read up on, so any pointers are appreciated.
EDIT:
To clarify this further, I want to have a table view where the buttons are (View A & B), and by clicking them they will cause the other window/view to change it's contents.
It's like the split view in the iPad settings application, there is a table view on the left, and when it's pressed the right side changes.
The radio buttons are there only to illustrate that I want more than one Document. I'm guessing I need more than one to handle this? Or perhaps I should place them all in a single NSDocument? Somehow that doesn't seem right.
To achieve what you want you need one window (NSWindow), one window controller and various views each with their own view controller. There are several ways you could set this up, all depending on your requirements:
You'd have at least 3 views (instances of NSView): one for the selection of the document class, one for the view selection and one for the content. Each view is controlled by a view controller (instance of NSViewController). Additionally you can opt to wrap the views in split views (NSSplitView) so your user can resize the real estate available to each view.
You have one window with a window controller. If you choose a Document based app template in Xcode, Xcode will generate a subclass of NSDocument which you can use as your window controller (or choose to use Core Data and Xcode will generate a subclass of NSPersistentDocument with all bells and whistles you need to access Core Data for document persistency).
So to come back to your questions:
1: Yes, but depending on your requirements. If Doc #1 is a completely different thing than Doc #2 than you might need to re-evaluate. For example Doc #1 might have completely different persistent requirements than #2.
2: There's no single scenario here, but one that worked for me: Take the project template for a document based app (with or without Core Data). Use the generated subclass of NSDocument (or NSPersistentDocument) as your window controller. Use NSView to implement the views in your window where each view is managed by its own controller, which is an instance of NSViewController.
I know this is an old question, but a way to do it how you want would be to use: ContainerViews and set their embed segue to be the view controllers you want.