Repost: Main window, key window, front window... I'm from Carbon, help me!
Repost: Main window, key window, front window... I'm from Carbon, help me!
- Subject: Repost: Main window, key window, front window... I'm from Carbon, help me!
- From: Sailor Quasar <email@hidden>
- Date: Thu, 24 Jul 2003 12:27:43 -0400
- Resent-date: Fri, 25 Jul 2003 14:35:08 -0400
- Resent-from: Sailor Quasar <email@hidden>
- Resent-message-id: <email@hidden t>
- Resent-to: email@hidden
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?
By the way, I would like to profusely thank James Quick for his
suggestion that I take a step back to examine my programming model.
Doing so has revealed several inadequacies that I have since begun to
rectify, and ultimately simplified my job by a significant amount.
-- Sailor Quasar, High Codemaster of the Web, scourge of systems
MacOS is to Windows as Terminus is to Trantor.
Email: email@hidden
-- Sailor Quasar, just another player in The World
"Come with me in the twilight of the summer night for awhile"
Email: email@hidden
_______________________________________________
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.