Re: Lining up NSViews in NSScrollView
Re: Lining up NSViews in NSScrollView
- Subject: Re: Lining up NSViews in NSScrollView
- From: daniel <email@hidden>
- Date: Mon, 21 Feb 2005 00:34:05 -0800
It sounds like you're taking advantage of a coincidence of the current
implementation.
In your example, why can't you make your NSMatrix into a matrix of
"radio button + extra controls" composite cells? It seems like that
would be cleaner and guaranteed to work as expected. It would also give
you greater flexibility over your design since obviously the controls
that "overlap" are meant to be in the proximity of their NSMatrix
neighbors. If you decide to redesign the spacing of your matrix, you
won't have dependencies on outside views.
I do "break a few rules" myself, sometimes. But that means I have to
pay extra special attention to every release from Apple to make sure
that my luck hasn't run out. I certainly don't break them when there
is a reasonable alternative.
I wouldn't advise people asking for solutions on a mailing list to buy
into some undocumented behavior. It's better for people to understand
the rules before they decide to break them.
Daniel
On Feb 20, 2005, at 10:17 AM, Ricky Sharp wrote:
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