Re: -[NSWindow orderOut:] vs. -[NSWindow performClose:]
Re: -[NSWindow orderOut:] vs. -[NSWindow performClose:]
- Subject: Re: -[NSWindow orderOut:] vs. -[NSWindow performClose:]
- From: Kyle Sluder <email@hidden>
- Date: Tue, 17 May 2011 19:37:34 -0700
On Tue, May 17, 2011 at 5:55 PM, Jeff Johnson
<email@hidden> wrote:
> I believe that the main purpose not only of -isReleasedWhenClosed but also NSWindowWillCloseNotification is to handle memory management and/or clean up when you're permanently done with a window. Indeed, the link above explains how you would use NSWindowWillCloseNotification for exactly that purpose. The method -orderOut: has no such side effects, because it's meant for temporarily removing a window from the screen, not getting rid of the window altogether.
>
> It's true that if you don't release either the window or the window controller when the window closes, then -close is pretty much equivalent to -orderOut:, but I don't think that's how the designers intended people to use the API.
Well, perhaps it will be helpful to elaborate on why the two methods
seem so similar in my case.
I have a multiple-window, but not document-based app. Think similar to
iTunes, including the sidebar, but it supports multiple windows. I've
got a shared "New/Edit Item" panel. The items it creates live in the
sidebar of the app's windows. This panel can be summoned by a toolbar
item or a menu item. The menu item can also be used to dismiss the
panel, consistent with system panels like the Font or Colors panel.
When the panel is summoned, I want the panel to remember the
"document" window on whose toolbar item the user clicked, or none if
the panel was summoned by the menu item. This is because I want to
bring that window forward when I dismiss the panel, or if the menu
item was used I will just bring the frontmost document window forward.
So when I bring up the panel, I register as an observer of the
document window's NSWindowWillCloseNotification. If the document
window disappears while the panel is still visible, my panel removes
itself as an observer of the close notification and forgets about the
now-dying document window, reverting to the same behavior as if it was
summoned by the menu item.
Likewise, I need to deregister for notifications when I dismiss the
panel first (the typical case). So I figured the panel's window
controller's -windowWillClose: method is the right place to do that.
But the "toggle" functionality sends -orderOut: to the panel,
consistent with how system panels are dismissed. This, of course, will
not send -windowWillClose:.
I could easily change my code to call -close instead of -orderOut:.
But every time I have to choose between -orderOut: and -close, this
question arises, and I figured I should just go ahead and ask it.
It feels like "close" semantics are appropriate for my dismissing my
search panel, rather than "hide". But the question remains why
-orderOut: is so prevalent when dealing with panels that exhibit
similar modality, like color wells which cause the shared color panel
to attach themselves.
It also doesn't help my understanding that the close button isn't
wired up to plain -orderOut:. So clicking the close button on a system
standard panel follows a different code path than a lot of code out
there. Maybe this is an indication that, according to the framework's
logic, my panel's window controller should have a documentWindow
property, and that both -windowWillClose: and whoever calls -orderOut:
should be responsible for resetting that property. After all, that
could very well be how NSColorWell is implemented. That seems rather
redundant and fragile, though.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden