On Tue, May 17, 2011 at 5:55 PM, Jeff Johnson <publicpost...@lapcatsoftware.com> 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
