IB 3 z-order problem

  • Hello!

    Has anyone else noticed that the front-back order in IB seems not to
    work properly?

    I realized I had to send to back the item I wanted to stand in front
    of all others in the running application and vice versa.

    Flofl.
  • Wdyp <mailto:<wdyp...> wrote (Sunday, December 9, 2007 9:44
    AM +0100):
    > Has anyone else noticed that the front-back order in IB seems not to work properly?

    There's no Z-ordering problem in IB because there's no Z-ordering.

    Cocoa/IB do not support overlapping NSViews, so all order issues
    are either ignored or arbitrary. The behaviour of overlapping
    NSViews is undefined and unpredictable.

    From <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/C
    ocoaViewsGuide.pdf
    >:

        Note: For performance reasons, Cocoa does not enforce
    clipping among
        sibling views or guarantee correct invalidation and drawing behavior
        when sibling views overlap. If you want a view to be drawn
    in front of
        another view, you should make the front view a subview (or descendant)
        of the rear view.

    --
    James Bucanek
  • I believe this is only problem with instances of NSCustomView.

    Jon Hess

    On Dec 9, 2007, at 8:44 AM, Wdyp <wdyp...> wrote:

    > Hello!
    >
    > Has anyone else noticed that the front-back order in IB seems not to
    > work properly?
    >
    > I realized I had to send to back the item I wanted to stand in front
    > of all others in the running application and vice versa.
    >
    > Flofl.
  • Hey James -

    On Dec 9, 2007, at 10:16 AM, James Bucanek <subscriber...>
    wrote:

    > Wdyp <mailto:<wdyp...> wrote (Sunday, December 9, 2007 9:44 AM
    > +0100):
    >> Has anyone else noticed that the front-back order in IB seems not
    >> to work properly?
    >
    > There's no Z-ordering problem in IB because there's no Z-ordering.
    >
    > Cocoa/IB do not support overlapping NSViews, so all order issues are
    > either ignored or arbitrary. The behaviour of overlapping NSViews is
    > undefined and unpredictable.
    >

    This is actually only true on 10.4 and previous versions of Mac OS X.
    On 10.5 it is fully supported.

    Jon Hess

    > >:
    >
    > Note: For performance reasons, Cocoa does not enforce clipping
    > among
    > sibling views or guarantee correct invalidation and drawing
    > behavior
    > when sibling views overlap. If you want a view to be drawn in
    > front of
    > another view, you should make the front view a subview (or
    > descendant)
    > of the rear view.
    >
    > --
    > James Bucanek
  • this is not true on 10.5 and the doc needs to be updated.

    10.5 allows overlapping views just fine.

    On Dec 9, 2007, at 1:16 PM, James Bucanek wrote:

    > Cocoa/IB do not support overlapping NSViews, so all order issues are
    > either ignored or arbitrary. The behaviour of overlapping NSViews is
    > undefined and unpredictable.
    >
    > From <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/C
    ocoaViewsGuide.pdf
    > >:
    >
    > Note: For performance reasons, Cocoa does not enforce clipping
    > among
    > sibling views or guarantee correct invalidation and drawing
    > behavior
    > when sibling views overlap. If you want a view to be drawn in
    > front of
    > another view, you should make the front view a subview (or
    > descendant)
    > of the rear view.
  • Le 10 déc. 07 à 02:23, Scott Anguish a écrit :

    > this is not true on 10.5 and the doc needs to be updated.
    >
    >
    > 10.5 allows overlapping views just fine.

    Great!
    Then what about the problem I’m having? Has anyone noticed it?
    Are there some settings I might have forgotten to consider?

    Flofl.
  • > Then what about the problem I’m having? Has anyone noticed it?

    Not sure if this is the same thing you're seeing, but I've notices
    that it becomes impossible to manipulate nested views (say, a button
    in a custom view in a scrollview) when anything has its "Wants Core
    Animation Layer" property checked. Maybe it is the same for
    overlapping ones?

    Any time I need to change anything in IB, the first thing I have to do
    is turn off all the layers, then make my change, then remember to turn
    layers on again. Do you know if any of your views have "Wants Core
    Animation Layer" checked?

    Cheers,
    -Joshua Emmons
  • Le 10 déc. 07 à 19:35, Joshua Emmons a écrit :

    >> Then what about the problem I’m having? Has anyone noticed it?
    >
    > Not sure if this is the same thing you're seeing, but I've notices
    > that it becomes impossible to manipulate nested views (say, a button
    > in a custom view in a scrollview) when anything has its "Wants Core
    > Animation Layer" property checked. Maybe it is the same for
    > overlapping ones?
    >
    > Any time I need to change anything in IB, the first thing I have to
    > do is turn off all the layers, then make my change, then remember to
    > turn layers on again. Do you know if any of your views have "Wants
    > Core Animation Layer" checked?
    >
    > Cheers,
    > -Joshua Emmons
    >

    No, that’s not what I was talking about but you’re right, this is
    another inconvenience.
    I think that in IB3 the use of the shortcuts for next/previous child/
    sibling is encouraged to cycle between objects in a view or window.

    Flofl.
previous month december 2007 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