• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Drawing order (was: Re: Any tricks to dragging an NSTableView?)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Drawing order (was: Re: Any tricks to dragging an NSTableView?)


  • Subject: Re: Drawing order (was: Re: Any tricks to dragging an NSTableView?)
  • From: Andy Lee <email@hidden>
  • Date: Thu, 20 Apr 2006 04:00:21 -0400

On Apr 20, 2006, at 2:45 AM, Sherm Pendley wrote:
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:?

Child views are indeed drawn somewhere other than in -drawRect:. The docs say: "The default implementation does nothing."


I suppose -drawRect: could send each subview a -setNeedsDisplay:NO after drawing it.

Shouldn't sending -display clear the "dirty" flag already?

Views don't have a dirty flag. Rather, at any given time during a window update, the window has a dirty region, so to speak (I'm sure that's not its proper technical name); it's an area of the window that has been specified as needing to be redrawn. The drawing that you do in -drawRect: is automatically cropped to that dirty region, and the region is also used to determine what subviews to send - drawRect: to in the first place.


Bottom line: subviews aren't good at being Sketch-like shapes where z- ordering might matter and where non-views might need to get drawn over them. Would it help if we could have more control over the order of subview drawing? Maybe, but we'd still have to at least consider performance issues, since there's setup overhead involved in drawing each view.

--Andy

_______________________________________________
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


References: 
 >Any tricks to dragging an NSTableView? (From: Jason Rusoff <email@hidden>)
 >Re: Any tricks to dragging an NSTableView? (From: "I. Savant" <email@hidden>)
 >Re: Any tricks to dragging an NSTableView? (From: Jason Rusoff <email@hidden>)
 >Re: Any tricks to dragging an NSTableView? (From: Andy Lee <email@hidden>)
 >Re: Any tricks to dragging an NSTableView? (From: Sherm Pendley <email@hidden>)
 >Re: Any tricks to dragging an NSTableView? (From: Scott Anguish <email@hidden>)
 >Re: Any tricks to dragging an NSTableView? (From: Andy Lee <email@hidden>)
 >Drawing order (was: Re: Any tricks to dragging an NSTableView?) (From: Sherm Pendley <email@hidden>)

  • Prev by Date: Re: memory leak in readInBackgroundAndNotify
  • Next by Date: Re: Localization
  • Previous by thread: Drawing order (was: Re: Any tricks to dragging an NSTableView?)
  • Next by thread: Of Bindings, NSOutlineView, and custom row backgrounds
  • Index(es):
    • Date
    • Thread