Re: Repost: Main window, key window, front window... I'm from Carbon, help me!
Re: Repost: Main window, key window, front window... I'm from Carbon, help me!
- Subject: Re: Repost: Main window, key window, front window... I'm from Carbon, help me!
- From: Dustin Voss <email@hidden>
- Date: Fri, 25 Jul 2003 14:35:17 -0700
On Thursday, July 24, 2003, at 09:27 AM, Sailor Quasar wrote:
Apologies for reposting, but a clear answer to this question is
somewhat critical to me.
As a relative newbie to Cocoa and an old hand at Carbon, I'm very much
used to the Carbon paradigm of window management: front window, active
window, front non-floating window, active non-floating window. In
Cocoa, things seem a bit different. There's no obvious concept of
"front" or "floating" at all that I can find. Instead we have the
"main" and "key" windows, and while it's very clear how they relate to
the responder chain, it's very UNclear how a window becomes either or
both of those.
My more specific current dilemma is this. I need to find the topmost
non-modal window, unless it's a specific window (to which I have an
NSWindow*) in which case I want the next window down. Since this
window is of an NSWindow subclass that returns NO from
canBecomeMainWindow, I've so far been using [NSApp mainWindow] with
success for this (given that I'm making specific allowances for modal
windows of course). What I want to know is: is this the best way, or
am I playing with the sacred Olympian fire which I shall be chained to
the mountain for daring to covet for the use of mere mortals?
A litte deeper info: the window I want to exclude is in fact acting as
a floating window (app only, not system-wide) to which all key input
goes (I've used a bit of a hack into NSApplication and NSWindow for
this, which is a whole different thing that another thread on this
list failed to resolve satisfactorally). What I need is for a user
action in that floating window to cause a corresponding response in
the [otherwise] topmost window. The user action is an IBAction wired
to the First Responder of course, but in the case of the floating
window being key, the First Responder ends up being that window and in
that case I need to determine the next window down. It sounds simple
to say that I could just prevent said window from becoming the first
responder, but that could easily interfere with the hack I've done to
handle key input and I'm not sure how to do it anyhow. Wouldn't that
interfere anyway with proper keyboard response even if I wasn't doing
any routing of key events?
[NSApp orderedWindows] will give you an NSArray of windows from front
to back, including panels, sheets, and modal dialogs. I think this will
give you the result you want.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.