AutoLayout: removeFromSuperview / removeConstraints throws exception and crashes hard

后端 未结 13 2202
谎友^
谎友^ 2020-11-27 11:05

We use auto layout constraints selectively, primarily to position labels in relation to editable field elements (UITextView, UITextField, typically). However, since impleme

相关标签:
13条回答
  • 2020-11-27 11:28

    In my case it was a proportional width constraint with 8:9 multiplier. I changed it to 7:9 and it worked.

    BTW the easiest way to find a constraint is to start removing views from view controller. Do it using binary algorithm :) removing half views, then half of the half that makes app crash, etc.

    0 讨论(0)
  • 2020-11-27 11:30

    As the other answers in this thread indicate this is somehow an invalid autolayout/contraint problem, though it appears to be very finicky about what qualifies as "invalid".

    Luckily I hadn't made many changes since my last commit and was able to track down the offending changes. For me having a view of 10 horizontal UIImageView with equal width and fixed 2:3 aspect ratio was the issue.

    The crash only seemed to occur after leaving the UIViewController that contained this image row. Each UIImageView was set to UIViewContentModeScaleAspectFill. Removing this content mode change (which was done before the UIImages were set) seemed to fix my problem but wasn't an acceptable solution. I ended up removing the aspect ratio restriction and just using a fixed width and height for each image.

    Why this was crashing my application I don't know... The crash could also ONLY be reproduce on an iPhone 4s running iOS 7.1.2. I tried to reproduce the same crash on an iPhone 4s simulator running iOS 9.1 without success. It also wouldn't crash when running on a phsyical iPhone 5 running iOS 9.1.

    Hope that helps someone out there

    0 讨论(0)
  • 2020-11-27 11:32

    Had the same issue, solved it by deleting constraints one at a time in IB until the crash was solved. This narrowed it down to the offending constraint. I then reinstated said constraint, but reversed the items:

    enter image description here

    You may be as lucky and be able to solve your AL problems as easily.

    0 讨论(0)
  • 2020-11-27 11:36

    I got this crash when I still have a missing constraint in wAnyhAny mode, fixing this removed the error.

    0 讨论(0)
  • 2020-11-27 11:39

    For anyone encountering this issue in any iOS version > 8.0, the Apple docs state to use the "active" property on the NSLayoutConstraint rather than the removeConstraint/addConstraint functions on UIView. Apple Docs addConstraint reference

    0 讨论(0)
  • 2020-11-27 11:39

    I just stumbled across the same error under OSX Mavericks with an OSX app I'm developing, but unlike the other answers given, I definitely don't have any other threads interacting with the UI objects, and the view hierarchy in question is definitely visible too. I'm not using blocks either. Bizarrely the problem went away when I removed a vertical constraint on an NSTextField.

    FWIW the problematic view whose removal from its superview causes the "internal error. Cannot find an outgoing row head for incoming head" error is one of many side-panel controls which together present the properties of objects in the main view which can be cut, copied, created etc. This means that the user can be pasting new objects into the main view quite rapidly, meaning the side-panel's controls are being destroyed and new ones created very rapidly, too. Of course, with everything in the main thread, this should not make a difference, but it seems to.

    The exact constraint causing problems was

    [self addConstraint: [NSLayoutConstraint constraintWithItem:control attribute:NSLayoutAttributeHeight relatedBy:NSLayoutRelationEqual toItem:other attribute:NSLayoutAttributeHeight multiplier:1.4 constant:0.0]];

    where control is the (editable) NSTextField causing problems, and 'other' is another (non-editable) NSTextField label.

    0 讨论(0)
提交回复
热议问题