I've created a pretty trivial case that makes this happen:
NSWindow* ontop = [[NSWindow alloc]
initWithContentRect:NSMakeRect(100.0, 100.0, 300.0, 400.0)
styleMask:NSTitledWindowMask | NSClosableWindowMask
backing:NSBackingStoreBuffered defer:NO];
NSWindow* onback = [[NSWind
On 21/10/2009, at 2:20 PM, Francisco Tolmasky wrote:
> So I've actually narrowed it down to the fact that my windows have a custom
> level. If the windows have the standard level then NSWIndowBelow works fine.
> Any known workarounds for this?
What happens when you call -setWindowLevel: on th
So I've actually narrowed it down to the fact that my windows have a
custom level. If the windows have the standard level then
NSWIndowBelow works fine. Any known workarounds for this?
Thanks,
Francisco
On Oct 20, 2009, at 11:40 AM, Jesper Storm Bache wrote:
Your analysis (regarding windo
On 21/10/2009, at 4:40 AM, Jesper Storm Bache wrote:
> Your analysis (regarding window visibility) sounds plausible as non-
> visible Cocoa windows have no "z-order".
> I have logged: "6802899 Please add latent z-order to hidden NSWindows"
> for this, but in the meantime I am left with having
Your analysis (regarding window visibility) sounds plausible as non-
visible Cocoa windows have no "z-order".
I have logged: "6802899 Please add latent z-order to hidden NSWindows"
for this, but in the meantime I am left with having to move "hidden"
windows off screen and make then visible (th
The title says it all, I set up a child window as such:
[targetWindow addChildWindow:self ordered:NSWindowBelow];
But the child window shows up on top of "targetWindow" until the first
click, at which point it immediately reorders itself to the back and
behaves correctly from that po
