Drawing order (was: Re: Any tricks to dragging an NSTableView?)
Drawing order (was: Re: Any tricks to dragging an NSTableView?)
- Subject: Drawing order (was: Re: Any tricks to dragging an NSTableView?)
- From: Sherm Pendley <email@hidden>
- Date: Thu, 20 Apr 2006 02:45:36 -0400
On Apr 20, 2006, at 1:49 AM, Andy Lee wrote:
On Apr 20, 2006, at 12:52 AM, Scott Anguish wrote:
On Apr 19, 2006, at 11:59 PM, Sherm Pendley wrote:
Obviously, the order in which subviews of the table view would be
drawn is undefined, but wouldn't a Sketch-like app define its own
-drawRect: for its top-level canvas view, which would iterate
through and draw the table view and its siblings in a known order?
well, yes.
I'm not so sure, and here's why.
Since the table views are subviews of the canvas view, the default
display logic will still proceed to draw those subviews after the
canvas view's -drawRect: is finished. So even if the canvas view's
-drawRect: draws the tables in the right order, they will just draw
themselves again and mess up that order.
Sorry for the topic drift - while this is obviously no longer
relevant to dragging a table view, I still want to understand what
I'm missing about z-ordering of child views.
Couldn't the overridden -drawRect: in the canvas view simply iterate
back to front through its children and send -display to each of them?
Why would the children draw themselves again, after you've done that?
Assuming that the canvas is a direct subclass of NSView, there would
be no need to call super's -drawRect:, and so no default display
logic to be concerned with.
Or, are child views drawn somewhere other than in -drawRect:? Is that
what I'm missing? I must be missing something, because while I
understand that the default drawing order is undefined, It seems like
it should be easy to override the default to get a well-defined
drawing order if you need one.
I suppose -drawRect: could send each subview a -setNeedsDisplay:NO
after drawing it.
Shouldn't sending -display clear the "dirty" flag already?
I don't actually know if that would work, but it feels sketchy, if
you'll pardon the pun.
I like puns. :-)
...this is more to the point -- whether one really wants to use a
view at all. If, along with circles and squares, you want to have
a graphic object that looks and behaves like a table view, using an
actual table view seems awfully convenient. The performance cost
of doing so may or may not matter depending on the application.
You'd still have the z-ordering problem, though.
You could take a image of the table view to use when the table view
is inactive. Double-clicking on this image would, instead of
selecting it for dragging around, resizing, etc., trigger "edit mode"
for the table view. For edit mode, instead of placing the table view
on the canvas, you could place it in a transparent window that sits
above the window with the canvas view. Since you *can* control the z-
ordering of windows, that would solve that issue.
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden