Re: NSBezierPath (again) and region subtraction.
Re: NSBezierPath (again) and region subtraction.
- Subject: Re: NSBezierPath (again) and region subtraction.
- From: Paul Fox <email@hidden>
- Date: Tue, 2 Jul 2002 22:01:48 +0100
>
On Tuesday, July 2, 2002, at 03:06 PM, Brian Webster wrote:
>
>
> The official stance is that NSView does not support overlapping views.
>
> Any views with the same superview that have overlapping frames will be
>
> drawn in an undefined order. It's true that they happen to be drawn in
>
> the order they are added to the superview, but that is an
>
> implementation detail and is subject to change. If you need to be able
>
> to have elements draw in a specific order, you should draw them all
>
> within the same view instead of using subviews.
>
>
Attached are 3 excerpts from the documentation which seem to indicate
>
that view ordering and overlapping is a legitimate concept for views,
>
although perhaps not recommended. I wouldn't do it.
>
>
-lance
>
>
>
NSWindow:
>
>
useOptimizedDrawing:
>
>
- (void)useOptimizedDrawing:(BOOL)flag
>
Informs the receiver whether to optimize focusing and drawing when
>
displaying its NSViews. The optimizations may prevent sibling subviews
>
from being displayed in the correct order-which matters only if the
>
subviews overlap. You should always set flag to YES if there are no
>
overlapping subviews within the NSWindow. The default is NO
>
>
NSView:
>
>
sortSubviewsUsingFunction:context:
>
>
- (void)sortSubviewsUsingFunction:(int (*)(id, id, void *))compare
>
context:(void *)context
>
Orders the receivers immediate subviews using the comparator function
>
compare, which takes as arguments two subviews to be ordered and the
>
context supplied, which may be arbitrary data used to help in the
>
decision. compare shouldreturn NSOrderedAscending if the first subview
>
should be ordered lower, NSOrderedDescending if the second subview
>
should be ordered lower, and NSOrderedSame if their ordering isn't
>
important.
>
>
addSubview:positioned:relativeTo:
>
>
- (void)addSubview:(NSView *)aView
>
positioned:(NSWindowOrderingMode)place relativeTo:(NSView *)otherView
>
Inserts aView among the receiver's subviews so it's displayed
>
immediately above or below otherView according to whether place is
>
NSWindowAbove or NSWindowBelow. If otherView is nil (or isn't a subview
>
of the receiver), aView is added above or below all of its new siblings.
>
Also sets the receiver as aView's next responder.
>
>
------------------------------------
>
Lance Bland
>
mailto:email@hidden
>
web charts at http://www.vvi.com/products/chart
Thanks Lance for pointing out the relevant bits of docs.
Am I going mad? Is drawing so deranged on the Mac? Or should I have
been using some other drawing element (e.g. NSCell?).
I think I would have to take exception about Cocoa being a window
management system like X or Win32.
Some people have a long way to go before they understand the principals
of windowing system design!
I do thank the people on this list for the help so far.
I have yet to say programming on the Mac is pleasant at all, and I am
glad my career doesnt rely on this.
regards
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.