Re: Child windows?
Re: Child windows?
- Subject: Re: Child windows?
- From: "Ian G. Gillespie" <email@hidden>
- Date: Thu, 30 Jan 2003 08:49:05 -0800
This is a question I asked a while ago and got no response from it, so
I will ask again since childWindow: as come up again. I am wondering
how I can have a childWindow be the first responder without the parent
window becoming "deactivated". I don't think I eloquently said that so
here is an example:
In Mail, when you begin typing in an address, a borderless window
appears with a table in it that has all a list of addresses that match
the one you are typing. Rows in that table are selected (so it is the
first responder?), but the scroll bars on the main composer window do
not gray out or become "deactivated". Anyone know how to get this
behavior?
On Wednesday, January 29, 2003, at 05:58 pm, James Pengra wrote:
In a document-style application I want to open a window in which
to make an analytical plot of some data. This window will always be
associated with with a main document window. I only want the window
visible when called by the user.
I could create a window with its own Nib file and Controller, but
I discovered the concept of a Child Window, and wonder if that would
be a better approach. I don't find a lot of discussion or use of
Child windows in the books I have, or even in Apple's documentation.
Not entirely sure what you mean by a child window, but If you're
opening a secondary view or alternate representation of the same
document's data/content, you'd probably do so by associating an
additional WindowController (and its window) with the same
DocumentController. I'm sure Aaron's and Scott's (et al) books discuss
the hierarchy of doc-controllers to window controllers to windows.
You'd just have two window controllers, each with its own window,
owned by the same doc controller.
[aWindow setChildWindow: bWindow] = bWindow attached to (/moves* with)
aWindow.
* It doesn't seem to move if the parent window is resized but you can
fix that easily by grabbing the didResize notification or by being the
parent window's delegate and working from there.
Anyway, given that - do you need the child window to move with the
parent?
If not and if it were me, I'd make a subclass of NSWindow w/ a
-auxWindow and -setAuxWindow:. That would let the "parent" close the
child as needed. Or, if it suits the situation better a controller
could deal with that.
If your auxiliary window will most likely be visible through the life
of the document I wouldn't bother with an extra nib. I use an extra nib
for controls/windows less likely to be requested right off the bat or
that aren't used all the time - mostly subjective.
HTH
_______________________________________________
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.