NSMenu pragmatisch auf Subclass von NSWindow setzen

Neee, es ist ja schon ok, dass du einen rechtsKlick im View verwalten willst. Das meinte ich nicht.

Bloß: Cocoa geht offenbar davon aus, dass rechtsKLicks nur in einem View Sinn machen und nur dort verwaltet werden. Der Trick mit dem sendEvent(NSWindow) war zwar eine nette Idee, kann aber nicht funktionieren, weil er aus einem Window kein View macht. Dazu gehört schon mehr.

Schön, dass es jetzt klappt. Allerdings meine ich, dass du im View jetzt auch ganz auf das Überladen von sendEvent verzichten kannst. Einfach mouseDown benutzen. Klappt das?

Original von Tom9811Bloß: Cocoa geht offenbar davon aus, dass rechtsKLicks nur in einem View Sinn machen und nur dort verwaltet werden. Der Trick mit dem sendEvent(NSWindow) war zwar eine nette Idee, kann aber nicht funktionieren, weil er aus einem Window kein View macht. Dazu gehört schon mehr.

+ (void)popUpContextMenu: (NSMenu*)menu withEvent: (NSEvent*)event forView: (NSView*)view; ist dein freund. Da brauchst du keinen view - einfach nil reinhauen. Habs eben getestet, geht auch super im fenstertitel. Das einzige problem, das ich noch habe ist das verschieben des fensters, aber auch das sollte kein problem sein

Max

Im Gegensatz zu der Doku der Schwestermethode ...withFont: steht in meiner Doku nicht, dass view nil sein darf. In der Doku steht vielmehr:

"You can attach a contextual menu to any NSView object."

Ich bin mit so etwas gaaaanz vorsichtig, zumal es keinen einzigen Grund dafür gibt, sich so etwas selbst zu stricken. Oder braucht jemand ein Fenster ohne View?

Original von Tom9811
Im Gegensatz zu der Doku der Schwestermethode ...withFont: steht in meiner Doku nicht, dass view nil sein darf. In der Doku steht vielmehr:
"You can attach a contextual menu to any NSView object."

von mir aus nimm auch die mit withFont: aber das macht keinen unterschied. Es geht und das reicht. Für Komplikationen gibt es schließlich tester.

Ich bin mit so etwas gaaaanz vorsichtig, zumal es keinen einzigen Grund dafür gibt, sich so etwas selbst zu stricken. Oder braucht jemand ein Fenster ohne View?

Hat das jemand gesagt?

Max

Es geht nicht, ob du die mit oder ohne Fonts nimmst. Das war ein Besippiel dafür, dass in der Doku üblicherweise steht, wenn du für ein Objekt nil übergeben darfst. Wenn das da nicht steht, darf man es in der Regel nicht.

Ein Tester kann auch nicht austesten, ob das, was du an de Doku vorbei machst $IRGENDWO und $IRGENDWANN zu einem Fehler führt.

Es ist völlig absurd, an der Doku vorbeizuprogrammieren um etwas zu erreichen, was ich doku-gemäß auch erreichen kann. Ich tanke ein Auto, welches Super will auch nicht Benzin, sage dann: Ach es fährt trotzdem doch, wenn zu allem Überfluss noch die Super-Säule gleich nebenan steht. Ebenso könnte ich mir auch ein Loch ins Knie bohren und das lustig finden.

Bereits das -sendEvent war an der Doku vorbei. Funktionierte angeblich nach "Tests". Es gab dann aber kurz nachher Probleme. Um diese Probleme auszugleichen, willst du jetzt das zweite Mal an der Doku vorbeiprogrammieren. Funktioniert nach "Tests" wieder. Man kann so natürlich sich nach und nach durch die Probleme hangeln und sich ein zweites Cocoa nebenher programmieren. Man kann es aber auch einfach so machen, wie es Cocoa vorsieht, wenn man noch bei einem Rest an klarem Verstand ist.

Original von Tom9811
dass in der Doku üblicherweise steht, wenn du für ein Objekt nil übergeben darfst. Wenn das da nicht steht, darf man es in der Regel nicht.

Das ist schlichtweg falsch. Genau das Gegenteil ist zutreffend. Als Beispiel die Doku zu NSMenuItem - (id)initWithTitle:(NSString *)itemName action:(SEL)anAction keyEquivalent:(NSString *)charCode:

"The arguments itemName and charCode must not be nil (if there is no title or key equivalent, specify an empty NSString)."

Es ist vollkommen Ok und auch gängige Praxis mit nil (auch als Parameter) zu arbeiten.

t.

Nein, ist es nicht. wenn du bitte mein Zitat aus der Doku liest!

Es gibt auch Fälle, in denen in der Doku auf das Gegenteil hinweist, bei den Container wird etwa auch immer darauf hingewiesen - weil das typische Fehler sind.

Aber wenn ein Parameter erwartet wird, dann darf man getrost davon ausgehen, dass Cocoa auch einen Wert erwartet, wenn nichts in der Doku steht. Das ist eigentlich schon selbstverständlich und dürfte bei >80% aller Methoden zutreffen. Machen wir eine Wette? Ich halte da schmerzlos 100,00 €! Ok?

Und das Cocoa offenbar davon ausgeht, dass man ein View einem Conntext-Menü zuordnet, zeigt sich nun an zahlreichen Stellen.

Original von Tom9811
wenn du bitte mein Zitat aus der Doku liest!

Die aktuelle Doku aus dem Web zu NSMenu + (void)popUpContextMenu:(NSMenu *)menu withEvent:(NSEvent *)event forView:(NSView *)view withFont:(NSFont *)font:

"Displays menu as a context menu over view for event using font. If you pass in nil for the font, the method uses the default font for menu."

Da steht weder explizit, daß view nil sein darf, noch steht da, daß es das nicht sein darf.

t.

*Dopppelpost*

Nochmal: Ich wollte das als Beispiel dafür anführen, dass die Doku eben zahlreich darauf hinweist, wenn man ein nil übergeben darf.

Ich hätte ebenso gut



nehmen können. Die von mir genannte Methode lag eben gerade herum.

So ein Hinweis fehlt aber gerade bei contextMenu .

Im Gegensatz ist es offenbar so, dass Cocoa Arbeit auf sich nimmt, um kein fensterbezogenes Kontextmenü zuzulassen. Alleine das lässt bei mir alle Alarmglocken läuten!

Wenn ich dann aber auch noch ein View herumfliegen habe (und ein viewloses Fenster ist mir ohnehin suspekt), für welches mir Cocoa sogar eine bequeme Implementierung anbietet, dann frage ich mich wirklich wieso ich jetzt den Umweg des Umweges gehen muss, um ans Ziel zu gelangen - und dann noch einen Umweg auf versumpften Boden.

Original von Tom9811
Nochmal: Ich wollte das als Beispiel dafür anführen, dass die Doku eben zahlreich darauf hinweist, wenn man ein nil übergeben darf.

Nun ja, das ist Deine Interpretation. Erstens gibt ebenso zahlreiche Beispiele, wo die Dokumentation darauf hinweist, dass ein nil eben nicht zulässig ist (und das hat dann wirklich Konsequenzen bei Nichtbeachtung). Ich denke, das weder der eine noch der andere Fall einen Schluss, ob nil grundsätzlich erlaubt ist oder nicht, zulässt. Zweitens steht da eigentlich nur, wie ein nil als Parameter von der Methode "interpretiert" wird und nicht, das es hier jetzt erlaubt ist. Und schließlich drittens müsstest Du dann mal Deine Art der Nutzung von Setter-Methoden überdenken. Denen übergibst Du ja auch wenn's denn sein soll ein nil. Bei den wenigsten Setter-Methoden in Cocoa steht dabei, dass nil erlaubt ist.

Original von Tom9811
Im Gegensatz ist es offenbar so, dass Cocoa Arbeit auf sich nimmt, um kein fensterbezogenes Kontextmenü zuzulassen. Alleine das lässt bei mir alle Alarmglocken läuten!

Ich glaube nicht, dass Cocoa da extra Arbeit auf sich nimmt, um das zu verhindern. Es ist wohl eher so, dass Cocoa das schlicht nicht implementiert hat.

Original von Tom9811
Wenn ich dann aber auch noch ein View herumfliegen habe (und ein viewloses Fenster ist mir ohnehin suspekt)

Hast Du schon mal mit gedrückter Befehlstaste in den Titel eines Fensters von Safari, Xcode oder im Finder geklickt? Wie zeigst Du solche Popups an?

Michael

Und wo wir gerade dabei sind: Es ging nicht darum, ein fensterbezogenes Menu zu erzeugen, zumindest nicht von der code-technischen Seite. Für den user sollte es so aussehen, als ob es so wäre. Das sagt noch lange nicht, wie es funkltionieren muss.

"You can attach a contextual menu to any NSView object."

Das steht nix davon, dass view nicht nil sein kann. Ein Menu KANN einem View zugewiesen werden, wenn keiner übergeben wird, dann gibt es halt einfach keinen view und dann kann es von ÜBERALL kommen.

Wenn man sich immer nur an die Doku hält und immer nur ganz strikt das macht, was da so drin steht und nicht anders, dann kommen höchstens mittelmäßige Programme raus, die kein einziges besonderes Zeichen haben. Komponenten zusammenschieben kann jeder. Das wichtige an der Interface-Programmierung ist ein Feeling zu erzeugen - und dazu gehören nun mal "illegale" Operationen, wie auch ein Menu auf ein Fenster. Oder glaubst du etwa, Programme wie ShapeShifter oder die ganzen MenuExtras, die man so überall findet, sich an die Doku halten??? MenuExtras wurden in 10.2 abgeschafft und ShapeShifter geht sogar mittlerweile so weit, dass sie nicht mehr die Bilder für das Interface im Systemordner ersetzen, sondern dass sie zur LAUFZEIT in die Laderoutine der Bilder eingreifen und die umlenken. (somit könnte jedes Programm ein eingenen look haben...) Du glaubst doch wohl nicht etwa, dass davon eine einzige Zeile dokumentiert ist? Gute Software braucht Innovationen, die dir ein Framework nicht bieten kann. Aber es kann dir die Möglichkeit bieten, eigenes zu erschaffen - und das auch mal ohne Doku und 500.000 kommentierte Beispiele.

Max

Eben! _Weil_ es nicht darum ging, gibt es _keinen_ Grund, es so zu machen. Exakt das sage ich.

Nein, in der Tat steht da nicht, dass es einem View zugewiesen werden muss. Das hatte ich deshalb auch nicht behauptet.

Falsch ist allerdings deine Übersetzung, dass es deshalb überall her kommen kann. Das ist ein Umkehrschluss.

Erstaunlich ist allerdings, dass sämtliche Methoden für Kontext-Menüs in Beziehung zu einem View stehen. Erstaunlich ist allerdings, dass viele Methoden auch nicht anders funktionieren. Dann liegt es nahe, dass Cocoa dies verlangt.

Ja, ich glaube, dass alle guten Apps an die Doku halten. Die Aussage, dass dies allenfalls mittelmäßige Programme sind, spricht für sich selbst und bedarf keiner weiteren Kommentierung. Und Innovation der von dir bezeichneten Art, eignet sich hervorragend für GIMP. Gute Software ist das beileibe nicht, sondern die Katatrophe schlechthin. Ein gutes Programm zeichnet sich nicht durhc eine "innovative GUI" aus, sondern durch gute Funktionalität, die in einem bestehendem System funktioniert. Alles andere ist User-Quälerei. Das als Vorbild zu nehmen, sagt dann alles Weitere, was nicht zu kommentieren ist.

1. Ich übergebe bei meiner Art der Setter, die übrigens nicht meine Art von Settern ist, keinesfalls an Cocoa-Setter nil. Ich übergebe das an eigene Setter. Aber das ist auch gleich, weil -und zwar gleichgültig, welche Form man nun verwendet- nil erlaubt ist. Sonst würde ich das auch nicht machen, da kannst du dir sicher sein.

Ja, ich schrieb ja schon, dass an einigen Stellen Cocoa auch das Gegenteil in der Doku sagt und nannte selbst eine, die typischerweise gefährlich ist (Container). Aber dennoch ist die Übergabe eines nicht-nil als aktueller Parameter ja der Standardfall. Und die allermeisten Methoden erwarten dort auch einen Wert. Mal ganz abgesehen von den Methoden, die mit

[CODE]if( !para ) {
return
}

beginnen ...

2. Ich habe freilich die Cocoa-Source hier nicht liegen. Wenn aber ein NSWindow sein event anders interpretiert als ein View, obwohl beides Responder sind, ist das Mehrarbeit. Es dürfte nämlich das Überladen bedingen. Das machte mich gerade stutzig! Da hat offenbar bei Apple jemand sich etwas gedacht. Zudem wird das in der Doku ausdrücklich erwähnt. Da hat sich bei Apple offenbar jemand noch etwas gedacht!

3. Meinst du nicht auch, dass die Titelleiste einen View enthält?

BTW: Michael, so gut ich dich jetzt kenne: Du würdest niemals so vorgehen!

Original von Tom9811
Und die allermeisten Methoden erwarten dort auch einen Wert.

Logisch, sonst hätte man den Parameter ja auch gleich weglassen können.
Bei der Methode +popUpContextMenu:withEvent:forView: hätte man den Parameter "forView:" wirklich weglassen können, denn der scheint mir rein gar nichts zu bewirken. Das Menü erscheint sowieso immer an der Mausposition, die im Event drin ist. Egal welchen View man mitgibt. Oder kennt einer die nutzbare Funktion dieses Parameters?

Original von Tom9811
2. Ich habe freilich die Cocoa-Source hier nicht liegen. Wenn aber ein NSWindow sein event anders interpretiert als ein View, obwohl beides Responder sind, ist das Mehrarbeit.

So ein Maus-Event geht doch folgenden Weg. Ins Programm rein kommt er in -sendEvent: von NSApplication, von dort wird der Event an -sendEvent: vom Key-Window weitergereicht und von dort wird die zum Event passende Responder-Methode des Views unterm Mauszeiger aufgerufen. Dieser View behandelt den Event oder reicht ihn an den nextResponder weiter. So geht's die Responder-Chain entlang, bis man wieder beim Fenster ankommt. Aber wie bereits jemand sagte, wird NSRightMouseDown eben nicht die Responder-Chain entlang durchgereicht und kommt deshalb beim Fenster nie an. -> keinerlei Mehrarbeit für NSWindow!

Original von Tom9811
3. Meinst du nicht auch, dass die Titelleiste einen View enthält?

Und wie komme ich an den dran?

Original von Tom9811
BTW: Michael, so gut ich dich jetzt kenne: Du würdest niemals so vorgehen!

So lange ich mit dokumentierten Mitteln an mein Ziel komme, wandre ich auf sicheren Pfaden. Wenn aber alle Stricke reißen, dann greif ich auch schon mal in die Trickkiste. Deswegen verzichte ich nicht auf gewünschte Funktionalität. Ist bisher aber erst einmal vorgekommen und ich habe auch schon ein ganz schlechtes Gewissen deswegen. :]

Michael

Original von Michael
Oder kennt einer die nutzbare Funktion dieses Parameters?

Das habe ich mich inzwischen auch schon gefragt. Entweder es ist ein verwaister NextStep Rest, was ich nicht wirklich glauben will, oder er könnte als Anker fungieren, um eine ActionMethode des Menus an die ResponderChain weiterzuleiten (also wenn der target des MenuItems nil ist). Auf dem Gebiet verlassen mich dann aber meine API-Kenntnisse etwas (und meine Lust), das weiter so ad hoc auseinanderzuklabüstern...

Überhaupt ist das soch eine recht merkwürdige Methode. Würde man nicht eher eine Instanzmethode als eine Klassenmethode erwarten..?

t.

Logisch, sonst hätte man den Parameter ja auch gleich weglassen können.
Bei der Methode +popUpContextMenu:withEvent:forView: hätte man den Parameter "forView:" wirklich weglassen können, denn der scheint mir rein gar nichts zu bewirken. Das Menü erscheint sowieso immer an der Mausposition, die im Event drin ist. Egal welchen View man mitgibt. Oder kennt einer die nutzbare Funktion dieses Parameters?

Er wird etwas bewirken, weil Cocoa ja auch an anderer Stelle bei Kontext-Menüs offenbar etwas mit dem View macht. Deshlab hatte ja Wolf die entsprechende Fehlermeldung. Ich weiß auch nicht, was Cocoa damit machen will oder -diese Möglichkeit bitte nicht vergessen!- eines Tages damit machen will. Ich sehe nur aus de Doku, dass die Methoden alle viewbezogen sind und respektiere das, zumal ich doch oihnehin ein View herumfliegen habe. Wozu also der Stress?

So ein Maus-Event geht doch folgenden Weg. Ins Programm rein kommt er in -sendEvent: von NSApplication, von dort wird der Event an -sendEvent: vom Key-Window weitergereicht und von dort wird die zum Event passende Responder-Methode des Views unterm Mauszeiger aufgerufen. Dieser View behandelt den Event oder reicht ihn an den nextResponder weiter. So geht's die Responder-Chain entlang, bis man wieder beim Fenster ankommt. Aber wie bereits jemand sagte, wird NSRightMouseDown eben nicht die Responder-Chain entlang durchgereicht und kommt deshalb beim Fenster nie an. -> keinerlei Mehrarbeit für NSWindow!

Ich hätte das andes implementiert, nämlich als Event-Filter eines jeden Responders. Aber es ist auch gleichgültig, ob das im Window gemacht wird oder im Event-verteiler. Es steht jedenfalls fest, dass Views und Windows unterschiedlich behandelt werden, was sicher nicht automatisch geschieht, sondern durch eine Abfgrage im Code. Das ist nicht nur Mehrarbeit, sondern doch offenbar kein Fehler, kein Seiteneffekt, sondern offenkundig Absicht. Zumal es auch in der Doku erwähnt wird.
Erst einmal: Da das nur auf dem Titelnamen selbst klappt, ist es ganz sicher eine Kontext-Menüs des entsprechenden Text-Feldes oder was auch immer Cocoa da hereinsetzt.

Nun, wie kommst du daran:
Sicher hat Das Window außer dem ContentView weitere Views. Ich _mutmaße_ dass borderView in Wahrheit die "höchste Instanz" ist. Wenn du also eine entsprechende Funktionalität implementieren möchtest, dann musst du die Fenstererzeugung überladen und dir ein entsprechendes View mit Kontext-Menü implementieren.
Möglicherweise kommst du auch über den Content-View heran, indem du "hochsteppst". Das würde ich allerdings auch nicht als sauber empfinden.

Original von Tom9811
Er wird etwas bewirken, weil Cocoa ja auch an anderer Stelle bei Kontext-Menüs offenbar etwas mit dem View macht.

Aber was?

Original von Tom9811
Deshlab hatte ja Wolf die entsprechende Fehlermeldung.

Aber der arbeitet doch gar nicht mit -popUpContextMenu:...

Original von Tom9811
Ich weiß auch nicht, was Cocoa damit machen will oder -diese Möglichkeit bitte nicht vergessen!- eines Tages damit machen will. Ich sehe nur aus de Doku, dass die Methoden alle viewbezogen sind und respektiere das, zumal ich doch oihnehin ein View herumfliegen habe. Wozu also der Stress?

Klar, wenn ich einen View habe, dann gebe ich den mit. Wenn ich aber die Situation habe, dass ich keinen View habe und die Methode auch mit nil als View klar kommt und auch nicht explizit verboten ist, dann sehe da kein Problem das auch zu machen.

Original von Tom9811
Ich hätte das andes implementiert, nämlich als Event-Filter eines jeden Responders.

Apple hat's nun mal so implementiert.

Original von Tom9811
Aber es ist auch gleichgültig, ob das im Window gemacht wird oder im Event-verteiler. Es steht jedenfalls fest, dass Views und Windows unterschiedlich behandelt werden, was sicher nicht automatisch geschieht, sondern durch eine Abfgrage im Code.

NSWindow ist das "Eingangstor" für alle das Fenster betreffende Events. NSWindow wertet den Event aus und wählt darauf basierend die entsprechende Responder Chain aus. Das macht NSWindow für jeden Event, auch für NSRightMouseDown. Das NSRightMouseDown beim NSWindow selbst nicht ankommt, liegt daran, dass dieser Event nicht in der Responder Chain weitergereicht wird. Das ist auch sinnvoll, weil der Superview ja wieder ein anderer Kontext wäre.

Original von Tom9811
Das ist nicht nur Mehrarbeit, sondern doch offenbar kein Fehler, kein Seiteneffekt, sondern offenkundig Absicht.

Ja, dieses Verhalten ist von Apple so gewollt. Wird aber nicht durch Mehrarbeit erreicht, sondern durch schlichte Unterlassung des Weitereichens eines Events. Also eher weniger Aufwand.

Michael

Aber was

Was intereesiert mich das? Wozu benötige ich diese Information. Ich sehe, dass Kontext-Menüs offenbar mit Views zusammenhängen. Dann nehme ich mir ein View. Wenn ich mal den aberwitzigen Fall haben sollte, dass ich ein viewloses Fenster habe, dann werde ich mich damit eigehend beschäftigen un dir das Ergebnis mitteilen.

Aber der arbeitet doch gar nicht mit -popUpContextMenu:...

Offenbar ist es so, dass Kontext-Menüs irgendwie mit Views zusammenhängen. Wir wissen nicht wieso, wir wissen nicht wie. Es ist aber so. Was ist jetzt so schwer daran, dies zu akzeptieren?

NSWindow ist das "Eingangstor" für alle das Fenster betreffende Events. NSWindow wertet den Event aus und wählt darauf basierend die entsprechende Responder Chain aus. Das macht NSWindow für jeden Event, auch für NSRightMouseDown. Das NSRightMouseDown beim NSWindow selbst nicht ankommt, liegt daran, dass dieser Event nicht in der Responder Chain weitergereicht wird. Das ist auch sinnvoll, weil der Superview ja wieder ein anderer Kontext wäre.

Michael, wenn etwas unterschidlich bei verschiedenen Objekten, die von einem Vaterobjekt abgelitet sind, behandelt wird, dann gibt es zwei Möglichkeiten.

1)
Irgendwo in der Software wird das unterschieden. Etwa


oder es wird eine gemeinsame Verteilermethode aufgerufen, die für NSView und NSWindow verschieden programmiert ist.

In beiden Fällen hast du Mehraufwand, den du bewusst machst. Wenn du alle Fälle einzheitlich behandelst, dann kannst du eine Methode ohne Abfrage im Vater machen und diese immer wieder verwenden. Was ist weniger Aufwand?

2)
Das ist schwarze Magie, die den einfach ohne Abfrage und Überladen dafür sorgt, dass manchmal x und manchmal nicht x gemacht wird.

Ich tendiere vorsichtig zu der Möglichkeit 1. Aber vielleicht kannst du mir als Pseudo-Code hierhin schreiben, wie es kommt, dass es unterschiedlich behandelt wird:

Original von Tom9811

Aber was

Was intereesiert mich das?

Dich interessiert das vielleicht nicht, mich schon. Vor allem wenn man mir erklären will, dass man kein nil übergeben darf!

Original von Tom9811
Wozu benötige ich diese Information.

Um den Nutzwert dieses Parameters zu kennen und diesen gezielt ausnutzen zu können. Wie soll ich denn vernünftig Parameter übergeben, wenn ich raten muss, was ein Parameter bewirkt? Das was in der Dokumentation zu dem Parameter steht, bewirkt er jedenfalls nicht.

Original von Tom9811
Offenbar ist es so, dass Kontext-Menüs irgendwie mit Views zusammenhängen. Wir wissen nicht wieso, wir wissen nicht wie. Es ist aber so. Was ist jetzt so schwer daran, dies zu akzeptieren?

Also mir ist schon klar wieso Kontext-Menüs mit Views zusammenhängen, denn irgendwie muss man ja den Kontext definieren. Nur sehe ich keinen Grund, die Nutzung der Methode -popUpContextMenu:withEvent:forView: ausschließlich auf Kontextmenüs zu beschränken, wenn damit auch "allgemeine" Menüs ohne Kontext machbar sind. Was ist jetzt so schwer daran, zu akzeptieren, dass es auch ohne View geht?

Original von Tom9811
Michael, wenn etwas unterschidlich bei verschiedenen Objekten, die von einem Vaterobjekt abgelitet sind, behandelt wird, dann gibt es zwei Möglichkeiten.

Oder vielleicht sogar drei?

Original von Tom9811
1)
Irgendwo in der Software wird das unterschieden. Etwa

Quellcode

1. if( ![thisResponder isKindOfClass:[NSWindow]] ) {
2. // Lieber Michael, wir wolen das nicht, deshalb müssen wir eine Abfrage einführen
3. }

So wird es aber nicht gemacht. Die Views und Windows entscheiden selbst, was sie mit einem Event machen. Da gibt es keinen Wächter, der sagt "du darfst, aber du nicht".

Original von Tom9811
oder es wird eine gemeinsame Verteilermethode aufgerufen, die für NSView und NSWindow verschieden programmiert ist.

Es gibt auch keine gemeinsame, verschieden programmierte Verteilermethode. Wie ein Event "verteilt" wird, habe ich ja bereits beschrieben.

Original von Tom9811
In beiden Fällen hast du Mehraufwand

Es trifft nur keiner der beiden Fälle zu.

Original von Tom9811
2)
Das ist schwarze Magie, die den einfach ohne Abfrage und Überladen dafür sorgt, dass manchmal x und manchmal nicht x gemacht wird.

Nein, auch das ist es nicht. Es ist alles ganz logisch erklärbar. Ich sag ja, es gibt drei Möglichkeiten. :]

Original von Tom9811
Aber vielleicht kannst du mir als Pseudo-Code hierhin schreiben, wie es kommt, dass es unterschiedlich behandelt wird:

Der Schlüssel des Ganzen ist die Responder Chain und folgender Satz aus der Dokumentation

NSResponder’s default implementations of all event methods simply pass the message to the next responder, so if no object in the responder chain does anything with the event it’s simply lost.

Das bedeutet, damit NSView (und Subklassen von NSView) ein Kontextmenü beim Klicken mit der rechten Maustaste anzeigen können, muss NSView die NSResponder-Methode -rightMouseDown: überschreiben. Sonst passiert da gar nix. Da NSWindow kein Kontextmenü anzeigen will, braucht NSWindow -rightMouseDown: auch nicht überschreiben -> der Mehraufwand für NSWindow etwas nicht zu tun ist also null.

Michael