On Mar 3, 2010, at 4:30 PM, Graham Cox wrote: > > On 04/03/2010, at 3:50 AM, Eric Gorr wrote: > >> Unfortunately, that knowledge won't help me solve the problem in front of me > > But it might help if you told us what the problem in front of you actually > was. A simple and obvious solution might then become clear. > > Put it this way: apps don't typically need to know why a window is being > closed. More generally, object methods shouldn't need to know who called > them. The reason you're finding it awkward/difficult to do is because it's > unnecessary.
The windows in question are a NSPanels. One of the questions which must be answered is should this NSPanel be visible at the next application launch. Now, what seems to be common is that if an NSPanel is visible when the application is quit, it should be visible at the next launch. Furthermore, if the user closes the NSPanel first and then quits the application, the NSPanel will not be visible at the next launch. Now, there are other means that will cause the NSPanel to be closed with different answers to whether or not it should be visible at the next launch. The only method (currently) for closing the panel which seems difficult to determine is whether or not the user has clicked in the close (red) button. However, it does appear that -windowShouldClose: is the easiest way to do it._______________________________________________ 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
