可可：接收塢站圖標點擊已經運行的應用程序

我正在編寫一個應用程序，並在應用程序啓動時顯示一個主窗口。當窗口關閉時，我希望應用程序繼續運行（使用菜單欄菜單），並且如果用戶再次單擊停靠欄圖標，我希望主窗口再次顯示。可可：接收塢站圖標點擊已經運行的應用程序

我約90％的方式：我的應用程序在Cmd-W關閉主窗口後正常運行，並且由於「關閉時釋放」未選中，窗口可能是[makeKeyAndOrderFront：] - 編輯以在點擊停靠欄圖標時再次顯示它。

這個謎題唯一缺失的部分是攔截實際的碼頭圖標點擊。

關於此主題的其他線程建議在窗口控制器中實現applicationShouldHandleReopen：hasVisibleWindows：或applicationShouldOpenUntitledFile：。我已經完成了這兩件事，但都沒有人接到電話。

還有其他想法嗎？

分配給'NSApplication'的實際委託是什麼？這就是方法應該實施的地方。我不認爲窗口控制器自動接收用於應用程序委託的消息。 –

@KevinGrant：他們沒有。 –

關於此主題的其他線程建議在窗口控制器中實現applicationShouldHandleReopen：hasVisibleWindows：或applicationShouldOpenUntitledFile：。

這隻有在窗口控制器是應用程序的委託時纔是正確的。這是應用程序發送這些消息的對象。

雖然我不會讓窗口控制器成爲應用程序的代表。我通常讓他們兩個獨立的對象。使一個對象專門成爲應用程序的委託，並且當該對象接收到相關的委託消息時，向窗口控制器發送一條消息，告訴它做它需要做的事情。

其實，我通常在單窗口應用程序中做的是讓應用程序的委託創建並擁有窗口控制器。您可以通過丟棄WC來回應窗口關閉，並通過檢查您是否有WC以及如果沒有WC並創建一個（從而重新打開窗口）來響應重新打開。

2012-09-29 07:03:43

Peter：感謝您的評論。作爲一個架構問題 - 使窗口控制器和窗口委託單獨的對象有什麼優勢？是不是使用兩個對象來管理比一個對象更復雜的相同窗口？ –

@DavidStein：沒有。保持對象的責任定義清楚並清晰明確，使您的程序更易於理解。從代碼少的角度來看，它可能不是「更簡單」，但它更清晰，更易於理解。另一種選擇導致了「大泥球」：一個負有太多責任的對象 - 在極端情況下，只有一個對象（有時稱爲「上帝對象」）可以完成所有工作。 –

@DavidStein：也就是說，* window的* delegate和* application的* delegate是兩個不同的東西。窗口控制器應該是其窗口的代表，並且（IIRC）是默認的。你應該有一個單獨的對象作爲應用程序的委託。 –

使用[NSApp setDelegate:self];在awakeFromNib。

2012-09-29 06:00:32

這不是必需的。如果此對象位於MainMenu筆尖中，則可以將代表插座連接到此處。如果它位於MainMenu筆尖以外的筆尖，則不應將其自身設置爲應用程序的代表。 –

回答