I would recommend to debug and find which constraint is "the one you don't want". Suppose you have following issue:
Always the problem is how to find following Constraints and Views.
There are two solutions how to do this:
- DEBUG VIEW HIERARCHY (Do not recommend this way)
Since you know where to find unexpected constraints (PBOUserWorkDayHeaderView) there is a way to do this fairly well. Lets find UIView
and NSLayoutConstraint
in red rectangles. Since we know their id in memory it is quite easy.
- Stop app using Debug View Hierarchy:
- The next is to find NSLayoutConstraint we care about:
As you can see, the memory pointers are the same. So we know what is going on now. Additionally you can find NSLayoutConstraint
in view hierarchy. Since it is selected in View, it selected in Navigator also.
If you need you may also print it on console using address pointer:
(lldb) po 0x17dce920
<UIView: 0x17dce920; frame = (10 30; 300 24.5); autoresize = RM+BM; layer = <CALayer: 0x17dce9b0>>
You can do the same for every constraint the debugger will point to you:-) Now you decide what to do with this.
PRINT IT BETTER (I really recommend this way, this is of Xcode 7)
- set unique identifier for every constraint in your view:
- create simple extension for
NSLayoutConstraint
:
SWIFT:
extension NSLayoutConstraint {
override public var description: String {
let id = identifier ?? ""
return "id: (id), constant: (constant)" //you may print whatever you want here
}
}
OBJECTIVE-C
@interface NSLayoutConstraint (Description)
@end
@implementation NSLayoutConstraint (Description)
-(NSString *)description {
return [NSString stringWithFormat:@"id: %@, constant: %f", self.identifier, self.constant];
}
@end
- build it once again, and now you have more readable output for you:
- once you got your
id
you can simple tap it in your Find Navigator:
HOW TO SIMPLE FIX THAT CASE?
- try to change priority to
999
for broken constraint.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…