Re: Preventing mouse clicks from bringing a window to the front
Re: Preventing mouse clicks from bringing a window to the front
- Subject: Re: Preventing mouse clicks from bringing a window to the front
- From: Ricky Sharp <email@hidden>
- Date: Sat, 19 Feb 2005 09:32:41 -0600
On Feb 18, 2005, at 4:47 PM, Evan Schoenberg wrote:
I'd use -[NSWindow setLevel:] in combination with preventing key and
main states. See the docs[1] for details.
This is what I currently do in my app. My "blanking" windows use a
level of NSNormalWindowLevel + 1 and my "content" window uses a level
of NSNormalWindowLevel + 2. The main reason for the strange levels was
to avoid as many conflicts as possible with Expose. If you end up
using values of NSNormalWindowLevel and NSNormalWindowLevel + 1,
respectively, I believe Expose will auto-hide your content window and
tile, highlight, etc. your blanking (background) window.
As a side note, if you do find problems with Expose, I recommend filing
an enhancement that basically requests a method to "mark" windows as
being ignored/recognized by Expose.
On Feb 18, 2005, at 6:09 PM, Tim Hewett wrote:
I **think** you can do this by making one of the windows a
child of the other and then defining how they are to be ordered.
So you could set your "always behind" window to be a child
of the "always front" one and it should then keep that ordering
even when clicked.
This is definitely worth looking at. The problem I have with using the
window levels is that it banks on the fact that there are several
values between the level constants (i.e. an implementation detail).
For example, the "distance" between NSNormalWindowLevel and
NSFloatingWindowLevel is more than at least 2 (don't recall the actual
number offhand). In my app, I also put windows (e.g. custom help tags)
at NSFloatingWindowLevel and thankfully they are above my main windows.
In asking Apple engineers if this implementation detail would ever
change, they said no, but didn't rule it out completely.
Hopefully this weekend I'll give Tim's suggestion a whirl. Will post
the results.
___________________________________________________________
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