前一篇提到 NSWindow 跟其他平台上面處理 Window 不一樣的地方，現在來講些一直以來我覺得 NSWindow 討厭的地方。

首先，在 Cocoa 對 Window 的設計中，有個你光看名字實在看不懂什麼意思，不看文件不可能猜得到的屬性，叫做 Key Window－你可以決定一個 Window 是不是 Key Window，也可以詢問目前的 Window 是不是 Key Window。

※ Key Window 與 Main Window

Key Window 是什麼意思呢？從字面來看，好像是什麼關鍵 Window，一個 Window 作為關鍵是什麼意思？或是拿來當做鑰匙的 Window 是什麼意思？

Key Window 當中的 Key 完全不是指這個，而是正在負責處理鍵盤事件的 Window，比方說，你有一個應用程式有一個 Window，裡頭有的文字框，你正在這個文字框裡頭打字，這個 Window 就是 Key Window。

跟 Key Window 相關的另外一個屬性叫做 Main Window，Main Window 通常是 Key Window，但是 Key Window 不見得是 Main Window。

我們來用 Safari 瀏覽器解釋這件事情－在 Safari 裡頭，我們可以產生很多個瀏覽器視窗瀏覽網頁，但是在瀏覽器裡頭想要打一篇文章的時候，突然發現不知道怎麼打，於是我們叫出了字元面板，然後把輸入焦點移動到了字元面板下方的搜尋框裡頭。這時候，字元面板就是我們的 Key Window，後面其中一個瀏覽器視窗則是 Main Window。

這兩個屬性決定了事件的傳遞：當使用者在鍵盤上面按了一個鍵，目的自然是想要在字元面板的搜尋框裡頭打字，所以我們要把這個事件送到字元面板上，我們就該把鍵盤事件分派到 Key Window；但如果是其他的操作行為，像是我們從書籤選單上面選了一個書籤，自然不會是由字元面板處理，而是當前的瀏覽器視窗開啟書籤，那就要送到 Main Window 上。

要讓一個 Window 變成 Main Window 或 Key Window，就是透過 NSWindow 的 makeMainWindow 與 makeKeyWindow 這兩個 method。於是你就可以看到官方文件裡頭讓人想要罵人的地方－打開 Xcode 裡頭附的開發者文件，可以看到 NSWindow 部分中， 關於這兩個 method 的解釋：

makeKeyWindow
Makes the window the key window..

makeMainWindow
Makes the window the main window.

沒什麼問題。好，在 iOS 裡頭，有一個可以對應到 NSWindow 的物件，叫做 UIWindow，UIWindow 沒有 makeMainWindow，只有 makeKeyWindow 以及 makeKeyAndVisible（就是你開始學寫 iPhone 應用程式的第一課中，在 applicationDidFinishLaunching: 裡頭呼叫，讓應用程式 Window 顯示出來的 method），>文件裡頭則是這麼說：

makeKeyWindow
Makes the receiver the main window.

喂喂喂…。

※ Cocoa 的 Events

這後面牽涉到 Cocoa 怎麼傳遞事件，作業系統收到鍵盤或滑鼠事件之後，首先決定要由哪個應用程式負責，可能是交由目前使用者正在使用的應用程式，也可能是某個常駐應用程式，應用程式（NSApplication）收到事件後，就會透過 sendEvent: 把事件傳遞給應該處理的 Window，這就是 Key Window 與 Main Window 派上用場的時候了，接著，NSWindow 繼續透過 sendEvent:，把事件傳遞給應該負責處理的 UI 元件。

同一個 Window 上面，可能有很多的 UI 元件，可能有一堆按鈕、一堆文字框，NSWindow 應該把事件傳遞給哪一個呢？當然是使用者正在用的那個。

所謂的「正在用」，在 Cocoa Framework 裡，稱之為 First Responder。如果你寫過 iPhone 可能就知道，想要讓某個文字框可以不用等到使用者點選，就取得輸入焦點、浮出螢幕鍵盤，就是讓這個文字框變成 First Responder，像是呼叫：

[textfield becomeFirstResponder];

在 Mac OS X 裡頭，我們則是要讓 NSWindow 決定他上面的哪個元件應該變成 First Responder：

[[textfield window] makeFirstResponder:textfield];

岔個題－在設定 target/action 的時候，如果把 target 設定成 nil 的話，就相當於呼叫 First Responder。在你的第一堂 iPhone 或 Mac 開發課程的講義中，你學到在 Interface Builder 裡頭拉一個按鈕出來，然後按著 Ctrl 按鍵，用滑鼠拉出一條連接線連到你的 controller 物件的某個 IBAction 上，對你的按鈕來說，這個 controller 就是 target，指定的 IBAction 就是 action。

在 iPhone 上如果要用程式完成這樣的連接，我們會呼叫 UIButton 的 addTarget:action:forControlEvents:，在 Mac 上面則是呼叫 NSButton 的 setTarget: 與 setAction:。你可以在這邊把傳入的 target 設成 nil，效果也就相當於，在 Interface Builder 裡頭，把連接線連到一個叫做 First Responder 的圖示上，圖示是一個紅色的箱子。

在 iPhone 上可能不常這麼做，但是在 Mac 上則會大量用到，比方說，我們在任何的文字框中，都可以用 Edit 選單裡頭的 Copy 指令複製文字內容。代表 Copy 指令的 NSMenuItem 自然不可能連接到應用程式裡頭所有的文字框上，而是連到 nil、連到 First Responder 上，看到使用者在用哪個文字框，才去複製那個文字框的文字。

※ sendEvent:

NSApplication 與 NSWindow 其實已經幫你完成大部分的事件傳遞，那，到底什麼時候會有必要自己處理 sendEvent:，還要搞清楚事件是被傳到了 Key Window 還是 Main Window？

在漫長的人生中，你可能會遇到這樣的狀況－你在寫一個媒體播放程式，可能是放影片或是放音樂，這個程式裡頭有好幾個 Window，有的 Window 播放影片、有的播放音樂，你可以把某個影片檔案從 Finder 拖到這個應用程式的 Dock Icon 上，就會開出一個新視窗，用新視窗播放影片。印象中 QuickTime 的 Tutorial 就是教你怎麼寫一份這樣的東西。

前一篇我們提到，這樣的應用程式就是 document-based application，所以你產生了一個繼承自 NSDocument 的新文件，這個 NSDocument 所管理的 Window 中有一個 QTMovieView，你直接把 NSDocument 讀到的 fileURL 丟給 movie view 產生 QTMovie，可以播放影片了。你現在想要讓軟體操控變得更容易一點。

首先你想到的是在螢幕畫面最上方的 menu bar 裡頭，增加一個選單，裡頭有要求影片播放或暫停的選項，還可以有一些透過改變 Window 大小來縮放影片的功能，你甚至在 Interface Builder 裡頭，把選單都加上了鍵盤快速鍵，像是用 cmd + 2 就可以變成兩倍大小。這時候我們都用不到 sendEvent:，但是，因為我們有很多個 Window、很多個影片，播放或暫停等命令不會送到固定的地方，所以要讓 First Responder 處理，我們把 target 都設成 nil。

我們打算用 play: 實作播放，用 pause: 實作暫停，這些 method 我們都放在我們的 NSDocument 子類別裡。如此一來，在 Main Window 裡頭沒有任何一個佔據輸入焦點的 UI 物件可以處理 play: 與 pause: 時，就會把事件送到 NSDocument 上。Xcode 提供的 template 裡頭，很多預設的 NSMenuItem 其實都把 action 送到 NSDocument 上，像，用 cmd + s 儲存檔案呼叫 NSDocument 的 saveDocument: ，還有列印等。

然後就遇到了問題－在 Mac 的鍵盤上，有一組按鍵叫做 Media Keys，在我的 MBP 與 MB 上是放在 F7 – F9 的位置，平常可以用來控制 iTunes 的播放、下一首上一首以及音量，你覺得如果是在你的應用程式中，這些按鈕應該是用來控制你的影片用的。可是，NSApplication 根本就不幫你處理這些按鍵，收到之後直接無視。

在 iOS 上面其實也有相同的狀況。iPad 可以透過藍芽連接無線鍵盤，iOS 4.0 之後，iPhone 也可以，如果使用者買了一組蘋果的藍芽鍵盤連接這些裝置，這些裝置也都會收到這些按鍵，甚至耳機線控也都是送出一樣的事件。

iOS 4.0 公開了這部份 API，找個地方實作 remoteControlReceivedWithEvent: 就好，至於 Mac 呢，則要看 Rogue Amoeba 前幾年的文章：Apple Keyboard Media Key Event Handling。

這篇文章首先就告訴你，要攔截這些事件，就是要透過 subclass NSApplication，改寫 sendEvent:，遇到 NX_KEYTYPE_PLAY （代表按下 play 鍵）等事件，就另外處理，不然就用 super 的實作。知道了是這些特別事件，在我們這個個案中，有幾個方向可以選擇：

一，我們可以把 NSEvent 再送給 Main Window，叫 Main Window 繼續用 sendEvent: 處理。在這個例子裡頭這麼做頂麻煩就是了，因為按下播放鍵的行為就是要播放影片，所以直接找到哪個是我們要的 NSDocument 物件，呼叫我們實作的 play:，會輕鬆取多。於是－

二，去找到底哪個 NSDocument 應該做事，也就是 Main Window 所屬的 NSDocument 物件。有兩種方法，1. 呼叫 [[[NSApp mainWindow] windowController] document]、2. 呼叫 [[NSDocumentController sharedDocumentController] documentForWindow:[NSApp mainWindow]]。