Getting the compiler warning:
Unsupported Configuration:
Unknown pattern color for the Background Color attribute
on my xib when trying to set the background color of a UIView to clear in interface builder. I swear I've made a UIView clear in the past without any trouble. Google isn't giving me anything useful. I feel like there is a head-slapping-simple answer here but after 14 hours at the keyboard (not on this issue) my tired mind isn't figuring it out.
I had lot of problem with the same issue. I solved this by this way
"select the UIView in interface builder, background color first set default color in option and build it".
I started getting this warning after updating to Mavericks and Xcode 5.1.1
I read elsewhere that the clearColor was the cause of this warning but in my case it was a pattern very similar to the standard Apple dark grey style background you see after updating an iPhone. No idea how it got there, don't remember ever asking for a pattern rather than a color nor how to select a pattern in the color selector popup. Perhaps it was chosen by IB because something in my original code was missing.
I changed it to Default, rebuilt and the warning has not returned. The only problem was going through each UIView until I found the one causing the warning because the background preview dropbox control in attributes is tiny.
Once aware of it, the pattern can be seen instead of a color
This is going to be a compile time error in XCode 8 (beta). Storyboard wont even open.
So we need to open storyboard in editor mode in XCode 7.x and search for "pattern" text and find the view as suggested by #Gordon Dove and fix it by changing the pattern to a plain color.
Related
I got some very weird issue with some user of iOS 14.0.1
First he reported that the username and password fields of Login page have disappeared.
I thought how this can happened? app was even published in App Store, so I asked for a screenshot and he sent me this:
Previously I thought fields have really disappeared, but after checking code, storyboard, etc... and finding no clue, I checked the screenshot again minutely and I noticed that inputs are there but with color almost same as the background. I also noticed that the background of other inputs has changed the color to some grey (looking like disabled fields). The background of TextFields are set as "Default".In order to fix it in iOS 14, I'm having to set background in all of them as White and incase I disable anyone of them, I need to set color again as Grey (and previously all these were not needed). Does anybody is facing same?
Finally I got the problem so I'm posting the answer in case can help anybody.
The problem was that I was using System's Color and these types of colors can changed (drastically like from white to black) according to the iOS selected mode (Light or Dark).
My suggestion is avoiding System's colors as long as you want fixed colors.
And in case your device is out of date and has no Light/Dark mode, check here how to switch between the modes in simulator.
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.
I'm now building on OS X app using Xcode 5.0 and Cocoa, and when I used a lot of objects ranging from text field, text view, radio buttons, to check box, etc... and ran the simulator, it looks like working successfully. However, there are two warnings which are tagged with yellow triangles that read Misplaced view - Frame for "clip view" will be different at runtime in MainMenu.xib file.
What does the error mean? And how can I resolve the warnings? And finally, should I bother to work a bit harder to try to remove those warnings when I get to sell the app? (or does Apple still allow developers to sell an app even when it has some warnings but nonetheless sounds working?)
For your information, I didn't write any code in any of my files yet - just dragged objects out to Interface Builder, and edited and aligned those objects a bit and just ran it, which this book does (but this book assumes to use Xcode 4).
Thanks.
Xcode5 defaults to using Auto-Layout. The warnings mean that some of your UI elements do not have enough constraints set, so when you manipulate the UI (for example resize the window) things may look different than you intended.
When you open MainMenu.xib in Interface Builder, a yellow arrow should appear in the component section. Click that arrow and a view appears that explains the offending elements. Each has another yellow element that brings up a context menu with suggested fixes.
Optionally you can disable "Use Autolayout" of the nib.
I have an odd behavior with my app and I don't know where it comes from. I have implemented a NSScanner for a text view content that works very well. The scanner works in conjunction with the text storage to set attributes on the text storage string via text view delegate methods. However, each time I enter a space, the enclosing scroll view scrolls back to the top of the text view. Can anyone give me a hint where this comes from ?
Probably not much hassle for those more experienced than me, I found out the possible reason for this behavior (see above) so I post it here in case anyone will look for solutions for similar "problems". It seems that turning off "Non-contiguous layout" option in the XCode 4.x attributes inspector for the NSTextView in case will solve the problem. The documentation for NSLayoutManager provides more clues (under "Overview" section): "Noncontiguous layout is an optional layout manager behavior new in Mac OS X v10.5..."
Maybe somebody more experienced than me will provide more info on this and the reason of this behavior of the enclosing scroller view when non-contiguous option is checked (which is, by default).
I am stuck with the same problem and turning off "Non-contiguous layout" does solve the problem, but it gives rise to another problem which is that the NSTextView gets sluggish for 10k lines of text. A similar question has been answered differently but I wonder if it works. That solution also imposes some restrictions which may not be applicable to you though.
We are using a UITextView with a dark background. As such we have made the text white color in order to be easier to read. The problem is the magnify window that pops up when you hold down your finger to move the insertion point uses white for the text color as well. This makes it impossible to see exactly where the insertion point is.
Is it possible to independently control the text color used in the magnify window?
Here is a screen shot illustrating the problem.
I just did a quick test in here and it's working fine.
I tested with firmware 2.2.1, in the simulator and using a device.
This is what I did to test it:
1- Created a new View-Based project
2- edited the nib in the Interface Builder, added a UITextView, setting the text to white and the background to gray, leaving everything else default
Do you have something different?
Hmm, it works correctly in the Notes app. Not only is the background yellow, you also see the lines.
Maybe it depends on whether you set the background color directly on the UITextView or make it transparent and set the background color of its containing view?
I don't think you have any control over that. And I think you should file a bug report with Apple over that. It should be smarter than that.