Re: Changing order of views dynamically
Re: Changing order of views dynamically
- Subject: Re: Changing order of views dynamically
- From: Sergey Shapovalov <email@hidden>
- Date: Tue, 20 Mar 2007 10:16:18 +0300
Andreas,
thank you very much for your reply and for the link.
2. I don't need to swap the views. I need to swap the *order* of
the views.
Why? They should not overlap anyway. Please read:
http://developer.apple.com/documentation/Cocoa/Conceptual/
CocoaViewsGuide/WorkingWithAViewHierarchy/chapter_4_section_1.html
Especially:
"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."
Yes, I get the point and I admit that what I was going to do has been
illegal. But in order to provide a complete view of the issue to me,
could anyone please explain the following 3 things?
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?
When I found this function, I thought that it should work for the
following case. I have a view V and a subview SV1, and at run-time, I
want to add another subview SV2 to the view V, and I want SV2 to be
drawn above SV1. So I create SV2 and call
[V addSubview: SV2 positioned: NSWindowAbove relativeTo: SV1];
Is this illegal? If so, what is the legal use of this method?
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?
3. In my case, the relative positioning of overlapping sibling
subviews (via calling addSubview:positioned:relativeTo:) did work so
far. I mean, in my "time-line control" analog the subviews that were
added above are actually drawn above the subviews added below. Is it
just a case of good luck? Can this stop working with a next major Mac
OS X release?
Again: I'm not arguing, and I'm not defending my original approach. A
admit that I was wrong. Thank you all for pointing this out to me.
But now I just want to understand how things work in Cocoa...
Best regards,
Sergey.
_______________________________________________
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