Bottom-edge constraint not enforced in IB but is in runtime?

  • I have a split view with an NSView in the top part, and inside that are a couple of buttons with layout constraints to the bottom and left edge (standard distance).

    If I move the split bar in IB, the NSView resizes, but the buttons contained in it do not. However, if I move it in my running app, it appears to do the right thing.

    This makes it difficult to work in IB. Is it a bug?

    --
    Rick
  • I have a split view with an NSView in the top part, and inside that are a couple of buttons with layout constraints to the bottom and left edge (standard distance).

    If I move the split bar in IB, the NSView resizes, but the buttons contained in it do not. However, if I move it in my running app, it appears to do the right thing.

    This makes it difficult to work in IB. Is it a bug?

    --
    Rick
  • On May 14, 2012, at 16:55 , Bill Cheeseman wrote:

    >
    > On May 14, 2012, at 5:41 PM, Rick Mann wrote:
    >
    >> If I move the split bar in IB, the NSView resizes, but the buttons contained in it do not. However, if I move it in my running app, it appears to do the right thing.
    >>
    >> This makes it difficult to work in IB. Is it a bug?
    >
    > I found it necessary to add a couple of additional constraints programmatically, to constrain the view in each part of the splitview.

    What I'm finding is that it works correctly when my app runs, but does not behave as expected in IB. If I resize in IB, the buttons that are supposed to stick to the bottom of the upper pane do not move with the split handle.

    --
    Rick
  • Yes, this is a bug in IB.

    Kevin

    On 14 May 2012, at 01:23 , Rick Mann <rmann...> wrote:

    > I have a split view with an NSView in the top part, and inside that are a couple of buttons with layout constraints to the bottom and left edge (standard distance).
    >
    > If I move the split bar in IB, the NSView resizes, but the buttons contained in it do not. However, if I move it in my running app, it appears to do the right thing.
    >
    > This makes it difficult to work in IB. Is it a bug?
    >
    > --
    > Rick
  • I'm also finding that NSSplitView's pane views seem to have the translatesAutoresizingMaskIntoConstraints property set to true by default, even when built strictly in IB. Is this correct? Xcode 4.3.2.

    TIA,
    --
    Rick

    On May 16, 2012, at 9:18 , Kevin Cathey wrote:

    > Yes, this is a bug in IB.
    >
    > Kevin
    >
    > On 14 May 2012, at 01:23 , Rick Mann <rmann...> wrote:
    >
    >> I have a split view with an NSView in the top part, and inside that are a couple of buttons with layout constraints to the bottom and left edge (standard distance).
    >>
    >> If I move the split bar in IB, the NSView resizes, but the buttons contained in it do not. However, if I move it in my running app, it appears to do the right thing.
    >>
    >> This makes it difficult to work in IB. Is it a bug?
    >>
    >> --
    >> Rick
    >
  • > I'm also finding that NSSplitView's pane views seem to have the translatesAutoresizingMaskIntoConstraints property set to true by default, even when built strictly in IB. Is this correct? Xcode 4.3.2.

    Hi Rick,

    I really encourage you to watch all three WWDC 2012 videos on constraints. That will answer a lot of questions. Constraints are tricky for me and those sessions cleared up a lot of things including priorities. You'll watch someone setup constraints to do things that previously required a split view to handle.

    IB is trying to give you good constraints but more importantly it is always going to create valid constraints. I don't remember what the default setting is for translatesAutoresizingMaskIntoConstraints (and I can't find it in IB) but I'm sure that if you are using constraints that translatesAutoresizingMaskIntoConstraints should be NO.

    Good luck
    Marc
  • On Jul 9, 2012, at 7:57 , Marc Respass wrote:

    >> I'm also finding that NSSplitView's pane views seem to have the translatesAutoresizingMaskIntoConstraints property set to true by default, even when built strictly in IB. Is this correct? Xcode 4.3.2.
    >
    > Hi Rick,
    >
    > I really encourage you to watch all three WWDC 2012 videos on constraints. That will answer a lot of questions. Constraints are tricky for me and those sessions cleared up a lot of things including priorities. You'll watch someone setup constraints to do things that previously required a split view to handle.

    Well, see, this is the problem. I watched the first two videos (still have to watch the examples video), and IB and Lion are not behaving as advertised. According to the videos, if you're using constraints, the translates property should always be no (I may have misunderstood that). It should only be on for a NIB that isn't using autolayout, and in that case you can apply constraints in some places, and it'll apply them in others.

    But that's not what I'm seeing.
  • The default value of translatesAutoresizingMaskIntoConstraints for top level views in IB is YES on both Lion and Mountain Lion. But this can be disabled using the Attributes Inspector and uncheck "Translates Mask Into Constraints"

    Kevin

    On Jul 9, 2012, at 12:09 PM, Rick Mann <rmann...> wrote:

    >
    > On Jul 9, 2012, at 7:57 , Marc Respass wrote:
    >
    >>> I'm also finding that NSSplitView's pane views seem to have the translatesAutoresizingMaskIntoConstraints property set to true by default, even when built strictly in IB. Is this correct? Xcode 4.3.2.
    >>
    >> Hi Rick,
    >>
    >> I really encourage you to watch all three WWDC 2012 videos on constraints. That will answer a lot of questions. Constraints are tricky for me and those sessions cleared up a lot of things including priorities. You'll watch someone setup constraints to do things that previously required a split view to handle.
    >
    > Well, see, this is the problem. I watched the first two videos (still have to watch the examples video), and IB and Lion are not behaving as advertised. According to the videos, if you're using constraints, the translates property should always be no (I may have misunderstood that). It should only be on for a NIB that isn't using autolayout, and in that case you can apply constraints in some places, and it'll apply them in others.
    >
    > But that's not what I'm seeing.
  • Thanks a lot, Kevin. I didn't realize it was only for top-level objects; now I see it. It is correct that I should turn off translatesAutoresizingMaskIntoConstraints when using auto-layout?

    Thanks again
    Marc

    El jul 10, 2012, a las 11:01 a.m., Kevin Cathey escribió:

    > The default value of translatesAutoresizingMaskIntoConstraints for top level views in IB is YES on both Lion and Mountain Lion. But this can be disabled using the Attributes Inspector and uncheck "Translates Mask Into Constraints"
    >
    > Kevin
    >
    > On Jul 9, 2012, at 12:09 PM, Rick Mann <rmann...> wrote:
    >
    >>
    >> On Jul 9, 2012, at 7:57 , Marc Respass wrote:
    >>
    >>>> I'm also finding that NSSplitView's pane views seem to have the translatesAutoresizingMaskIntoConstraints property set to true by default, even when built strictly in IB. Is this correct? Xcode 4.3.2.
    >>>
    >>> Hi Rick,
    >>>
    >>> I really encourage you to watch all three WWDC 2012 videos on constraints. That will answer a lot of questions. Constraints are tricky for me and those sessions cleared up a lot of things including priorities. You'll watch someone setup constraints to do things that previously required a split view to handle.
    >>
    >> Well, see, this is the problem. I watched the first two videos (still have to watch the examples video), and IB and Lion are not behaving as advertised. According to the videos, if you're using constraints, the translates property should always be no (I may have misunderstood that). It should only be on for a NIB that isn't using autolayout, and in that case you can apply constraints in some places, and it'll apply them in others.
    >>
    >> But that's not what I'm seeing.
    >
  • On Tue, Jul 10, 2012, at 08:01 AM, Kevin Cathey wrote:
    > The default value of translatesAutoresizingMaskIntoConstraints for top
    > level views in IB is YES on both Lion and Mountain Lion. But this can be
    > disabled using the Attributes Inspector and uncheck "Translates Mask Into
    > Constraints"

    Unfortunately this is not the complete truth. It is also YES for
    document views of NSScrollViews, and cannot be disabled even in the
    latest versions of Xcode that I have tried. I have a view that manages
    its relationship to its enclosing clip view using constraints, and I
    obviously need to disable translatesAutoresizingMaskIntoConstraints for
    this to work properly.

    And because of the way that nib unarchiving works,
    -setTranslatesAutoresizingMaskIntoConstraints: is called *after*
    -initWithFrame:/-initWithCoder:. So the solution I've been using is to
    override -updateConstraints to call [self
    setTranslatesAutoresizingMaskIntoConstraints:NO] before calling super.

    I suppose I could instead override
    -translatesAutoresizingMaskIntoConstraints like so:

    - (BOOL)translatesAutoresizingMaskIntoConstraints {
      if ([self superview] == [[self enclosingScrollView] contentView])
        return NO;
      else
        return [super translatesAutoresizingMaskIntoConstraints];
    }

    ...but it's not documented whether the constraint system calls
    -translatesAutoresizingMaskIntoConstraints, or uses an internal flag to
    represent that state.

    Also, IB doesn't let you edit the autoresizing mask of a view in a nib
    with autolayout turned on, even if that view is a top-level view and
    should have translatesAutoresizingMaskIntoConstraints=YES because it's
    going to be installed in a view hierarchy you don't control. This is
    also incredibly unhelpful.

    --Kyle Sluder
previous month may 2012 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today