Re: Changing order of views dynamically
Re: Changing order of views dynamically
- Subject: Re: Changing order of views dynamically
- From: Michael Watson <email@hidden>
- Date: Tue, 20 Mar 2007 12:36:04 -0400
What on Earth is not precise about:
"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."
There are things in IB and NSView that appear to be planning for
future additions, but in the end, the documentation says not to
overlap views.
I think you filed a bug that should not have been filed.
--
m-s
On 20 Mar, 2007, at 12:28, Sergey Shapovalov wrote:
Andy,
well, I do agree that the outcome of the discussion is that either
the online documentation is not precise, or the API (and comments
provided along with it) are misleading because the documentation
and the API contradict each other. I think this is a place where we
need more clarification from Apple, so I've posted a bug (just like
you have recommended to do):
rdar://5074871
Best regards,
Sergey.
1. What is [NSView addSubview:positioned:relativeTo:] intended for
if relative positioning of overlapping subviews is not guaranteed
to work anyway? If "correct invalidation and drawing behavior when
sibling views overlap" is not guaranteed, is it just a misleading
API which will never work?
I don't know if it'll never work, but IMO it is indeed misleading,
because the doc for that function says quite clearly: "Inserts a view
among the receiver’s subviews so it’s displayed immediately above or
below another view."
This issue comes up often enough that I would expect the NSView
documentation to have been clarified. When I scan the NSView docs
and find a method that clearly claims to do what I want, I don't go
looking for a reason why that method shouldn't be relied on.
I'm incredibly late for work, but I'll try to remember to file a
bug. Perhaps you could do the same.
2. When I build a NIB resource in Interface Builder, I can choose
several sibling subviews in a parent view, and for each of them say
"Layout > Bring To Front" or "Layout > Send To Back". Is this also
illegal in case these sibling subviews overlap? I mean, is there no
guarantee that what was brought to front will be drawn above what
was sent to back?
The "Bring To Front" and "Send To Back" could just be conveniences in
case while running Interface Builder you hide one view behind
another. It could be that IB doesn't do the optimizations that are
referred to in the CocoaViewsGuide doc, which makes z-ordering work
in *IB*. This doesn't mean it'll work in your application.
I agree it's confusing, because if you've ever used a drawing
program, you make certain assumptions about what "Bring To Front" and
"Send To Back" mean.
--Andy
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
40bungie.org
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden