• 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: Lining up NSViews in NSScrollView
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lining up NSViews in NSScrollView


  • Subject: Re: Lining up NSViews in NSScrollView
  • From: Ricky Sharp <email@hidden>
  • Date: Sun, 20 Feb 2005 12:17:14 -0600


On Feb 20, 2005, at 11:02 AM, glenn andreas wrote:


On Feb 20, 2005, at 9:50 AM, Ricky Sharp wrote:

On Feb 20, 2005, at 2:45 AM, daniel wrote:

You can't "put views on top of other views." You can only put views inside other views. There must be a hierarchical relationship between all views in your window.

This isn't true. You can overlap views, but must be a bit more careful. For example, you shouldn't instruct the containing window to use optimized drawing (see useOptimizedDrawing:) when views overlap.


It's also documented as not being guaranteed to work:

file:///Developer/ADC Reference Library/documentation/Cocoa/ Conceptual/DrawViews/Concepts/ViewHierarchy.html#//apple_ref/doc/uid/ 20000909/BBCECAIF


For performance reasons, the Application Kit 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.





"App Kit does not [..] guarantee correct [..] drawing behavior when sibling views overlap" pretty much scares me away from trying such things. That you might be able to make it work as you expect it to doesn't mean that it's going to work the same in all versions of OS X either - seems like a good way to get some ugly drawing/event handling/whatever bugs that are going to be subtle and difficult to track down, consistently reproduce, and resolve across system versions...

While I agree with what you wrote, in practice, views can overlap. When they do, they do draw as expected based upon their z-order.


I currently have one case where my views needed to overlap:

(*) Choice A
    some controls here
( ) Choice B
    more controls here

Choice A and Choice B radio buttons are in an NSMatrix. The "some controls here" represent controls that ultimately are on top of the matrix. Since these are all custom controls/cells, I have complete control over their drawing. Since all my drawing just composites stuff over (i.e. I don't first erase the background), I don't see any rendering problems.

Furthermore, the controls are in the "dead" space of the matrix. One of the properties of the matrix is the y-spacing between cells.

In this particular configuration, although my views do in fact overlap, none of the cells overlap at all.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com


_______________________________________________
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


  • Follow-Ups:
    • Re: Lining up NSViews in NSScrollView
      • From: daniel <email@hidden>
References: 
 >Lining up NSViews in NSScrollView (From: Michael Marmarou <email@hidden>)
 >Re: Lining up NSViews in NSScrollView (From: daniel <email@hidden>)
 >Re: Lining up NSViews in NSScrollView (From: Ricky Sharp <email@hidden>)
 >Re: Lining up NSViews in NSScrollView (From: glenn andreas <email@hidden>)

  • Prev by Date: Re: Finding a view (Cocoa theory)
  • Next by Date: Re: NSApplication Bug or Feature: Keystroking -performClose closes all windows?
  • Previous by thread: Re: Lining up NSViews in NSScrollView
  • Next by thread: Re: Lining up NSViews in NSScrollView
  • Index(es):
    • Date
    • Thread