On May 19, 2012, at 4:46 AM, Jason Teagle wrote: >> Closing the last window of an application doesn't automatically quit it > ... >> The app is still running and current. Its menu is shown in the menu bar and >> you can still use it.
> This seems to be a problem though - clicking on it won't bring my main window > back. Am I supposed to respond to something here? As my app is still running > I assumed it would come back up automatically as if it had simply been > minimized rather than closed. It was not minimized. Apps can't be minimized, only windows can. Your app was simply running with no windows open. If it was current when you closed the window, it is still current. Check the menu bar. If you've switched away from it, you can switch back with Command-Tab. It is not expected that doing just that will create a new window. There's nothing "wrong" with an app that's running without windows. When you click on the Dock icon for a running app, it is a "relaunch" or "reopen app" event. The same is true if you were to go to the Finder and double-click on your app's icon while it was already running. In this case, it is expected that the app will created a new window if there isn't already a window open. However, that behavior is not entirely free. You have to implement some stuff. Cocoa handles the reopen event by checking if your app delegate implements -applicationShouldHandleReopen:hasVisibleWindows:. If doesn't or if it returns YES, then it checks if the delegate implements -applicationShouldOpenUntitledFile:. If it doesn't or if it returns YES, it calls -applicationOpenUntitledFile: if the delegate implements it. If the delegate does not and it is document-based, it invokes -openUntitledDocumentAndDisplay:error: on the shared NSDocumentsController. So, the short story is to implement -applicationOpenUntitledFile: to do whatever you want, either when your app is first launched or when it is "relaunched". This is documented in Cocoa Scripting Guide: How Cocoa Applications Handle Apple Events <https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ScriptableCocoaApplications/SApps_handle_AEs/SAppsHandleAEs.html>. You may be confused by the default project template for a Cocoa application in Xcode. In that project, the MainMenu NIB contains a window and that window is "visible at launch" (which really means "visible when the NIB is loaded"). Since the MainMenu NIB is loaded automatically when the app is first launched, the window in that NIB is presented. You didn't have to do anything in code to get that to happen. I feel this makes for a poor template for a first app. Its apparent simplicity is misleading and results in the sort of confusion you're experiencing. For example, since the presentation of the window happens automatically when the NIB is loaded, it's hard to see how and why it's happening. Furthermore, since the MainMenu NIB is not suitable for loading more than once, you can't reopen the window in the same way it was originally opened. You could reopen it by doing [window makeKeyAndOrderFront:self] from the -applicationOpenUntitledFile: method (assuming the window is *not* configured to Release When Closed in IB). In general, windows should be in separate NIBs, each of which should be owned and loaded by a window controller. If a window is to be loaded at application launch, that should be done in code in the -applicationOpenUntitledFile: method. That would make it clearer to new Cocoa developers what exactly is going on and how they might go about adding behaviors to an app. Regards, Ken _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
