On Apr 16, 2010, at 10:47 AM, Kyle Sluder wrote:
On Fri, Apr 16, 2010 at 10:37 AM, Corbin Dunn corb...@apple.com wrote:
You can't control it in IB (short of removing the view and adding it back
in). But in code, you can just call -addSubview:positioned:relativeTo: to
move views around in
On Apr 16, 2010, at 9:48 AM, Kyle Sluder wrote:
It works OK with non layer-backed views in my experience, but you do get a
build warning if sibling views overlap in a nib. Sibling views are drawn in
the order they appear in the parent's list of subviews (or possibly the
inverse order, I
On 18.04.2010, at 1:29, Jonathan Hess wrote:
On Apr 16, 2010, at 10:47 AM, Kyle Sluder wrote:
On Fri, Apr 16, 2010 at 10:37 AM, Corbin Dunn corb...@apple.com
wrote:
You can't control it in IB (short of removing the view and adding
it back in). But in code, you can just call -
On Apr 17, 2010, at 12:50 PM, Alexander Bokovikov wrote:
On 18.04.2010, at 1:29, Jonathan Hess wrote:
On Apr 16, 2010, at 10:47 AM, Kyle Sluder wrote:
On Fri, Apr 16, 2010 at 10:37 AM, Corbin Dunn corb...@apple.com wrote:
You can't control it in IB (short of removing the view and
For some reason I need to do a job which NSWindow usually does, when
it redraws itself (AFAIU) - I need to find all its views, which have z-
order higher than my view, then get their bounding rectangles, unite
them, subtract from the window content view bounding rectangle and
sect the result
On Friday, April 16, 2010 at 2:40 PM Norbert M. Doerner wrote:
NSView *rootView;
NSArray *mySubViews
rootView = [theWindow contentView];
mySubViews = [rootView subviews];
Thanks, it looks like I've found it. The only question is why Cocoa has no
Z-order term? I've read in the doc that it is
On Apr 16, 2010, at 3:16 AM, Alexander Bokovikov wrote:
Thanks, it looks like I've found it. The only question is why Cocoa has no
Z-order term?
Historically Cocoa did not support overlapping sibling views at all, so there
was no concept of z-order (other than a child view being in front of
On 15 apr 2010, at 13.06, Alexander Bokovikov wrote:
This is because my view uses QuickDraw to redraw itself, but those functions
draw on screen directly (AFAIU) and don't take into account other views,
located above current view.
Could anybody show the right way to go?
The right
Historically Cocoa did not support overlapping sibling views at all, so there
was no concept of z-order
(other than a child view being in front of its parent.) There is some support
for it now, but I’m not
sure how extensive it is, e.g. whether it only applies to layer-backed views
or
It works OK with non layer-backed views in my experience, but you do get a
build warning if sibling views overlap in a nib. Sibling views are drawn in
the order they appear in the parent's list of subviews (or possibly the
inverse order, I don't precisely recall). The exact effect you get
On Apr 16, 2010, at 8:38 AM, Joar Wingfors wrote:
On 15 apr 2010, at 13.06, Alexander Bokovikov wrote:
This is because my view uses QuickDraw to redraw itself, but those functions
draw on screen directly (AFAIU) and don't take into account other views,
located above current view.
Also, IB had (has?) a bug where it would unarchive views in the
reverse order from which they were stored in the nib. IB does allow
you to reorder subviews, so if you are still being bitten by this you
could build your interface and then reorder the views such that they
are backwards. Then
On Fri, Apr 16, 2010 at 10:37 AM, Corbin Dunn corb...@apple.com wrote:
You can't control it in IB (short of removing the view and adding it back
in). But in code, you can just call -addSubview:positioned:relativeTo: to
move views around in the Z order.
IB has Send Forward/Backward items on
Hi, All,
For some reason I need to do a job which NSWindow usually does, when
it redraws itself (AFAIU) - I need to find all its views, which have z-
order higher than my view, then get their bounding rectangles, unite
them, subtract from the window content view bounding rectangle and
14 matches
Mail list logo
