Warum behandelt eine NSWindow- oder NSView-Instanz ihre eigenen Schlüsselereignisse und nicht ihren Delegaten?

Question

Als Neuling in Cocoa habe ich Schwierigkeiten zu verstehen, warum die generischen NSResponder-Unterklassen Schlüsselereignisse so implementieren, wie sie es zu tun scheinen.

In meinem Programm habe ich eine NSWindow-Unterklasse, die den gesamten Bildschirm einnimmt und unbedingt Schlüsselereignisse behandeln muss. Es gibt mehrere Hauptbefehle, die den gesamten Status des Programms ändern können (z. B. einen Zeitgeber pausieren, wenn der Benutzer die Leertaste drückt), wobei es nicht sinnvoll ist, Teilansichten wie ein NSTextField-Handle zu haben.

Es scheint mir, dass der Delegat (Controller) diese Ereignisse erhalten soll. Stattdessen muss ich entweder einen Haufen unordentlichen Klebstoffcode schreiben, damit das Fenster (über seine keyDown: und interpretKeyEvents: Selektoren) den Controller benachrichtigt, oder ich muss einfach eine Menge Controller-Code in die NSWindow-Unterklasse selbst verschieben.

Das ist chaotisch und mein Bauchgefühl sagt mir, dass ich etwas vermisse. Gibt es eine sauberere Lösung?

Answer 1

Wenn Sie es richtig eingerichtet haben, wird der Delegat NSWindow die Nachrichten empfangen. Cocoa verwendet die Responder-Kette, um Nachrichten vom ersten Responder weiterzuleiten - die Schlüsselansicht für Schlüsselnachrichten und die Ansicht, auf die/etc/angeklickt wurde. für Maus-Nachrichten - zurück durch die Superviews, durch das Fenster und schließlich zum Vertreter des Fensters. Es gibt ein ziemlich gutes Diagramm der typischen Antwortkette auf Apple's site.

Sie sollten nie NSWindow von der Unterklasse ableiten, es sei denn, Sie implementieren einige ausgefallene Fensterzeichnung oder etwas anderes in diesen Zeilen. Cocoa bietet die Klasse NSWindowController, um sich als Controller für ein Fenster und dessen Inhalt zu verhalten.

Das übliche Muster ist die Unterklasse NSWindowController und fügen Sie Ihre IBOutlet s hinzu, und verwenden Sie dann eine NIB, um Ihren Fensterinhalt auszulegen. Sie machen Ihre NSWindowController Unterklasse die Klasse des Dateieigentümer-Proxy in Interface Builder. Und Sie weisen dem Fenster-Controller auch die delegate des Fensters zu, so dass er Teil der Responder-Kette werden kann. Um schließlich Fenster zu erstellen, verwenden Sie NSWindowController 's Methode, die das Laden der NIB mit einem neuen Fenstercontroller als Besitzer der Datei automatisiert.

Ich würde empfehlen auf Fenster-Controller in der Cocoa-Dokumentation zu lesen, weil sie den fehlenden Link bieten, den Sie suchen.