NSMenu pragmatisch auf Subclass von NSWindow setzen

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

Nochmal: Ich habe nicht gesagt, dass dies verboten ist, sondern, dass alles dagegen spricht. Ich kümmere mich auch nicht um das Verhalten, weil ich es nicht benötige.

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

Ich glaube man kann ein View übergeben und dann funktioniert das. Mir reicht das. Alles andere ist Kapselung, die ich respektiere. Und du kannst mir auch nicht erzählen, dass du genau weißt, was mit einem Objekt getan wird, dass du einen addObject:(NSArray) übergibst. Das musst du auch nicht wissen. Es ist das System der Kapselung, dass du das nicht weißt. Das ist _Absicht_!

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?

Ich sehe den auch nicht. Und? Ich sehe nur, dass es offenbar eine Beziehung bei Cocoa gibt. Mich interessiert nicht, warum das so ist, zumal es gar keine Notwendigkeit gitb, das zu ändern. Was willst du mit einem viewlosem Fenster?

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.

Nur dass deine Ansicht sicher nicht stimmt:
Dann müsste aber bei Implementierung der rightMouseDown:-Methode diese aufgerufen werden, was Wolf versucht hat. Sie wurde nicht aufgerufen. Das zeigt ja gerade, dass die nicht aufgerufen weren soll und sich jemand darum kümmert, dass es auch nicht geschieht.

Da fragt vorher jemand ab, ob er die Methode aufruft in Abhängigkeit der Klasse.

Original von Tom9811
Nochmal: Ich habe nicht gesagt, dass dies verboten ist, sondern, dass alles dagegen spricht.

Das klang hier aber ganz anders:

Original von Tom9811
Im Gegensatz zu der Doku der Schwestermethode ...withFont: steht in meiner Doku nicht, dass view nil sein darf

Original von Tom9811
Ich glaube man kann ein View übergeben und dann funktioniert das. Mir reicht das.

Mir reicht es nicht, wenn nicht das passiert, was in der Dokumentation steht. Das Kontextmenü erscheint nämlich nicht "over" dem View wie es da steht, sondern an der Mausposition.

Original von Tom9811
Alles andere ist Kapselung, die ich respektiere. Und du kannst mir auch nicht erzählen, dass du genau weißt, was mit einem Objekt getan wird, dass du einen addObject:(NSArray) übergibst. Das musst du auch nicht wissen. Es ist das System der Kapselung, dass du das nicht weißt. Das ist _Absicht_!

Bei addObject: kenne ich aber den Nutzen den ich von der Parameterübergabe habe. Wenn die Kapselung so weit geht, dass sich mir der Sinn eines Parameters völlig entzieht, dann läuft da was verkehrt.

Original von Tom9811
Was willst du mit einem viewlosem Fenster?

Schon mal an Popup-Menüs ganz ohne Fenster gedacht? Zum Beispiel für kleine Helferprogramme, die im Hintergrund laufen und per globalen Tastatur-Shortcut ein Popup-Menü präsentieren.

Original von Tom9811
Nur dass deine Ansicht sicher nicht stimmt:

Nein, meine "Ansicht" kann ja gar nicht stimmen, weil sie ja nicht mit Deiner überein stimmt. Nur ist meine "Ansicht" die Realität. Die ist überprüfbar.

Original von Tom9811
Dann müsste aber bei Implementierung der rightMouseDown:-Methode diese aufgerufen werden, was Wolf versucht hat. Sie wurde nicht aufgerufen. Das zeigt ja gerade, dass die nicht aufgerufen weren soll und sich jemand darum kümmert, dass es auch nicht geschieht.

Da fragt vorher jemand ab, ob er die Methode aufruft in Abhängigkeit der Klasse.

Ach Tom, tsunamix hat es zuerst erwähnt und ich habe es jetzt glaube ich auch schon zweimal wiederholt: Die NSView-Implementierung von -rightMouseDown: reicht den Event nicht in der Responder-Chain weiter. Da der ContentView eines Fensters ein NSView (oder eine Subklasse von NSView) ist, wird -rightMouseDown: von NSWindow natürlich nicht aufgerufen. NSView fragt da auch nichts ab, sondern schneidet einfach die Responder-Chain durch. NSView ist also dieser "Jemand".
Du kannst ja mal eine Subklasse von NSView machen und in dieser Subklasse -rightMouseDown: folgendermaßen überschreiben.
Damit hättest Du wieder die Defaultimplementierung von NSResponder und die Responder-Chain an einer Stelle wieder geflickt. Wenn Du nun diese NSView-Subklasse als ContentView setzt, dann wird beim Rechtsklick auf diesen ContentView auch die -rightMouseDown: von NSWindow aufgerufen (siehe Bild).

Michael

Zitat von Zitat

Nein, das klang da nicht anders. Ich hatte darauf hingewiesen, dass üblicherweise die Doku mitteilt, wenn man nil verwenden darf und sie es in diesem Falle nicht tut. Das beudetet, dass es dagegen spricht, dass man es tun darf. Zwingend ist das nicht, hatte ich auch gesagt, weil es dann ein unzulässiger Umkehrschluss ist. Es ist ein Indiz, dass ich in eienr Vielzahl voon Indizien aufgezählt hatte. Bitte lies meine Beiträge!

Mir reicht es nicht, wenn nicht das passiert, was in der Dokumentation steht. Das Kontextmenü erscheint nämlich nicht "over" dem View wie es da steht, sondern an der Mausposition.

Mit Over meinen die wohl kaum eine x,y-Position oder ein Clipping. Hiermit dürfte dann auch der Sinn des Parameters klar sein.

Bei addObject: kenne ich aber den Nutzen den ich von der Parameterübergabe habe. Wenn die Kapselung so weit geht, dass sich mir der Sinn eines Parameters völlig entzieht, dann läuft da was verkehrt.

Mir erschließt es sich.

Schon mal an Popup-Menüs ganz ohne Fenster gedacht? Zum Beispiel für kleine Helferprogramme, die im Hintergrund laufen und per globalen Tastatur-Shortcut ein Popup-Menü präsentieren.

Nein, ich zeichne nicht in Bereiche, die nicht mir gehören. Daher würde ich ein Fenster mit einem View öffnen und das Pop-Up da zeichnen. Dann gehört mir auch dder Bildschirmbereich.

[Responderkette]

Und wieviele rightMouseButton willst du überladen? Vom document, vom ClipViewl, vom Scroll-View?
Und ist dann nicht für diesen Effekt rightMouseDwon in NSView gegenüber NSResponder überladen? Ist das nicht Mehrcode Hat dsa der Programmierer von rightMouseDown(NSView) bei Apple versehentlich eingetippt? Hat er dann, nachdem er versehentlich diesen Code eingetippt hat (genauer: Er hat gar keinen Code eingetippt, die Überladung ist von Gott selbst dorthin gekommen), ganz versehentlich dem Doku-Menschen Bescheid gesagt? (Dem hat es mutmaßlich ein Erzengel zugeflüstert!) Oder anders gesagt: Zeig mir doch bitte deine 0 Zeilen Code, die dazu führen, dass hier sich -rightMosueDown(NSView) anders verhält als -rightMouseDown(NSResponder)? rightMouseDown(NSResponder) reicht nämlich weiter!

Mir ist da noch ganz viel schwarze Magie unterwegs!

[Code-Beispiel]

BTW: Das ist nun der totale Wahnsinn. Ein Event, dass an ein View geschickt wird und dort verarbeitet werden soll, wird an das Fenster weitergereicht, damit es nicht vom View verarbeitet wird, was nicht geht, womit ich dann NSWindow erweitern muss, um eine Methode aufzurufen, die einen View_paremeter hat.

Ganz großer Code!

Wie wäre es, wenn man es so programmieren würde, dass in NSView das Event auf einen .Mac-Account geschireben würde und von NSWindows wieder gelesen würde. Das wäre noch etwas sinnvoller!
+++Update auf Michaels Update+++
Was meinst du mit "wieder geflickt? Da du ja behauptest, dass gar nichts zusätzlich implementiert ist, gibt es doch auch nichts "wieder" zu flicken?

Original von Tom9811
...dass üblicherweise die Doku mitteilt, wenn man nil verwenden darf

Falsch.

und sie es in diesem Falle nicht tut. Das beudetet, dass es dagegen spricht, dass man es tun darf.

Falsche Prämissen fürhren zu falschen Schlußfolgerungen.

Zwingend ist das nicht, hatte ich auch gesagt, weil es dann ein unzulässiger Umkehrschluss ist. Es ist ein Indiz, dass ich in eienr Vielzahl voon Indizien aufgezählt hatte.

Wir verhandeln nicht einen Indizienstrafprozeß. Das Verhalten von Objective-C ist definiert. Cocoa verhält sich entsprechend. Die Doku spiegelt das (idR) korret wieder, wenn auch, wie in diesem Fall ex silentio.

Bitte lies meine Beiträge!

Das tun wir. Ändert aber nichts am wahrheitsgehalt Der Aussagen.

t.

Original von Tom9811
Bitte lies meine Beiträge!

Ich lese Deine Beiträge und wenn Du immer wieder darauf pochst, dass wenn es nicht explizit in der Doku erlaubt wird nil zu übergeben, man es auch nicht machen soll, wie soll ich das dann deuten?

Original von Tom9811
Mit Over meinen die wohl kaum eine x,y-Position oder ein Clipping. Hiermit dürfte dann auch der Sinn des Parameters klar sein.

Sorry, Tom. Einfach sagen: "die meinen wohl kaum dieses oder jenes" und dann behaupten, damit ist der Sinn klar, ist ja wohl nicht Dein ernst. Bitte erkläre mir dann doch mal den Sinn dieses Parameters. Denn ob ich einen View übergebe oder nil führt zum gleichen Ergebnis. Erkläre mir bitte den Unterschied. Und bitte keine Ausweichmanöver mehr, dann lass es lieber ganz.

Original von Tom9811
Mir erschließt es sich.

Das ist schön für Dich. Dann bin ich wohl einfach zu doof.

Original von Tom9811
Nein, ich zeichne nicht in Bereiche, die nicht mir gehören. Daher würde ich ein Fenster mit einem View öffnen und das Pop-Up da zeichnen. Dann gehört mir auch dder Bildschirmbereich.

Wird bestimmt ein optischer Leckerbissen.

Original von Tom9811
Und wieviele rightMouseButton willst du überladen? Vom document, vom ClipViewl, vom Scroll-View?Und ist dann nicht für diesen Effekt rightMouseDwon in NSView gegenüber NSResponder überladen? Ist das nicht Mehrcode

Ach je, NSView hat -rightMouseDown: überladen, damit ein View beim Klick mit der rechten Mausetaste auf ihn darauf reagieren kann. Das ist Mehrcode in NSView, um eine bestimmte Funktionalität bereitzustellen.

Original von Tom9811
Hat dsa der Programmierer von rightMouseDown(NSView) bei Apple versehentlich eingetippt? Hat er dann, nachdem er versehentlich diesen Code eingetippt hat (genauer: Er hat gar keinen Code eingetippt, die Überladung ist von Gott selbst dorthin gekommen), ganz versehentlich dem Doku-Menschen Bescheid gesagt? (Dem hat es mutmaßlich ein Erzengel zugeflüstert!) Oder anders gesagt: Zeig mir doch bitte deine 0 Zeilen Code, die dazu führen, dass hier sich -rightMosueDown(NSView) anders verhält als -rightMouseDown(NSResponder)? rightMouseDown(NSResponder) reicht nämlich weiter!

Hallo? Jetzt wird es echt lächerlich. Das erzähle ich die ganze Zeit. Lies meine Beiträge. Ich darf ich Dich mal zitieren:

Original von Tom9811

Wenn aber ein NSWindow sein event anders interpretiert als ein View, obwohl beides Responder sind, ist das Mehrarbeit.

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, ...

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. }

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

In beiden Fällen hast du Mehraufwand,

DU bestehst die ganze Zeit darauf, dass NSWindow Extraarbeit auf sich nimmt, damit die eigene -rightMouseDown:-Methode nicht aufgerufen wird. Ich versuche Dir die ganze Zeit klar zu machen, dass dies nicht der Fall ist und sich das Verhalten durch die ganz normale Responder-Chain ergibt. Und jetzt willst DU mir auf einmal erzählen, das NSView die -rightMouseDown:-Methode überschrieben hat und dadurch der Event bei NSWindow nicht ankommt?

Original von Tom9811
Mir ist da noch ganz viel schwarze Magie unterwegs!

Die entspringt ganz allein Deiner Phantasie. Ich habe mit schwarzer Magie nichts am Hut.

Original von Tom9811

[Code-Beispiel]

[Polemik pur]

Dir ist ganz bestimmt klar, was ich mit diesem Codebeispiel bezwecken wollte. Das war ganz sicher nicht für die Praxis bestimmt. Deine Reaktion darauf spricht für sich und ich beende damit hier auch jede weitere Diskussion mit Dir. Es ist einfach nicht der Mühe wert. Ist zwar schade für die anderen Forumsteilnehmer, die dann teilweise auf falschen Informationen sitzen bleiben, aber ich habe einfach keine Lust mehr.

Michael

Ich lese Deine Beiträge und wenn Du immer wieder darauf pochst, dass wenn es nicht explizit in der Doku erlaubt wird nil zu übergeben, man es auch nicht machen soll, wie soll ich das dann deuten?

Genau so, wie ich es geschrieben habe: Dass es gefährtlich ist. Nicht: Dass es auf jeden Fall verboten ist. Das hätte ich nämlich sonst geschrieben.

Sorry, Tom. Einfach sagen: "die meinen wohl kaum dieses oder jenes" und dann behaupten, damit ist der Sinn klar, ist ja wohl nicht Dein ernst. Bitte erkläre mir dann doch mal den Sinn dieses Parameters. Denn ob ich einen View übergebe oder nil führt zum gleichen Ergebnis. Erkläre mir bitte den Unterschied. Und bitte keine Ausweichmanöver mehr, dann lass es lieber ganz.

Du hast es doch selbst geschireben, weshalb ich es nicht wiederholte. Offenbar wird damit die Z-Position bestimmt.

Wird bestimmt ein optischer Leckerbissen.

Was willst du denn sehen?
Aber ja das wird es. In eigene Bereiche zu malen, sorgt dafür, dass kein Müll übrig bliebt.

Ach je, NSView hat -rightMouseDown: überladen, damit ein View beim Klick mit der rechten Mausetaste auf ihn darauf reagieren kann. Das ist Mehrcode in NSView, um eine bestimmte Funktionalität bereitzustellen.

Das meine ich nicht. Diese Funktionalität muss ja proframmiert sein. Aber in NW(Window) wird es nicht weitergelteitet, obwohl es in der Basisklasse geschieht. Also muss es dort "leer" überladen sein.

BTW: Es gibt nicht um den Umfang des Aufwandes. Es geht darum, dass sich offenbar jemand etwas dabei gedacht hat, als er den Code eintippte. Auch wenn es nur drei Zeilen sind. Er muss sich dch etwas gedacht haben. Zumindest liegt das sehr nahe.

DU bestehst die ganze Zeit darauf, dass NSWindow Extraarbeit auf sich nimmt, damit die eigene -rightMouseDown:-Methode nicht aufgerufen wird. Ich versuche Dir die ganze Zeit klar zu machen, dass dies nicht der Fall ist und sich das Verhalten durch die ganz normale Responder-Chain ergibt. Und jetzt willst DU mir auf einmal erzählen, das NSView die -rightMouseDown:-Methode überschrieben hat und dadurch der Event bei NSWindow nicht ankommt?

Ich bestehe nicht darauf, dass NSWindow Mehrarbeit auf sich nimmt. Ich bestehe darauf, dass der Programmierer Mehrarbeit auf sich nimmt, wenn er in NSWindow ein anderes Verhalten implementiert.

Das entspringt sicher auch nicht meiner Phantasie. Wenn die Basismathedoe weiterreicht und in der abgeleiteten Klasse die Methode nicht weiterreicht, dann hat da jemand nachgedacht und gesagt: Oh, da darf ich nicht weiterreichen, muss also überschreiben.

Ich kann da keine Phantasie sehen!

Code-Beispiel

Richtig! Das ist Polemik pur! Es ist Polemik pur, wenn es eine einfache Möglichkeit gibt, das Feature zu implementieren und du dir eine völlig andere Implementierung überlegst, die vollkommen von hinten durch die Brust ins Auge ist, nur um dabei zu bleiben, dass man es auch so machen könnte.

Wolf ist damit jedenfalls ganz sicher nicht geholfen. Ganz im Gegenteil! Das ist schade für andere Forumsteilnehmer! In der Tat!

Falsch.

Nicht falsch. Gerade erst in einem anderen Thread liegt wieder ein Beispiel vor. Ich habe dir übrigens eine 80 % Wette angeboten. Die kannst du ja annehmen.

Falsche Prämissen fürhren zu falschen Schlußfolgerungen.

Exakt, deshalb führte die Idee auch zu einer Exception.

Wir verhandeln nicht einen Indizienstrafprozeß. Das Verhalten von Objective-C ist definiert. Cocoa verhält sich entsprechend. Die Doku spiegelt das (idR) korret wieder, wenn auch, wie in diesem Fall ex silentio.

Da, wie dankenswerterweise dies Michael berichtet hat, der Parameter für die Z-Position herangezogen wird, halte ich das für eine wüste Behauptung

Aber es ist e5rstaunlich, dass du aus deiner Kristallkugel weißt was die Doku ex silentio sagt!

Wleche Aussage von mir war nicht wahr?
____________________
____________________
____________________

Original von Tom9811
Du hast es doch selbst geschireben, weshalb ich es nicht wiederholte. Offenbar wird damit die Z-Position bestimmt.

wofür braucht das Menu die?

BTW: Es gibt nicht um den Umfang des Aufwandes. Es geht darum, dass sich offenbar jemand etwas dabei gedacht hat, als er den Code eintippte. Auch wenn es nur drei Zeilen sind. Er muss sich dch etwas gedacht haben. Zumindest liegt das sehr nahe.

Der Gedankenverlauf ging ungefähr so:

Brauche ich auf einem Fenster ein Menu?
- ja, manchmal
Welche?
- wenn du den pfad sehen willst
ahja, das mach ich mit apfel-klick
- genau
also brauche ich den rechtsklick einfach nicht
- exakt
hmmm
- ich lass ihn einfach leer

Ich bestehe nicht darauf, dass NSWindow Mehrarbeit auf sich nimmt. Ich bestehe darauf, dass der Programmierer Mehrarbeit auf sich nimmt, wenn er in NSWindow ein anderes Verhalten implementiert.

Ist das nicht eine kausale forderung, wenn jemand eingene Funktionalität implementieren will?

Richtig! Das ist Polemik pur! Es ist Polemik pur, wenn es eine einfache Möglichkeit gibt, das Feature zu implementieren und du dir eine völlig andere Implementierung überlegst, die vollkommen von hinten durch die Brust ins Auge ist, nur um dabei zu bleiben, dass man es auch so machen könnte.

Das ist gerade dein Fehler. Es ist eben nicht das selbe. Denn Fenster != View und wenn ich auf die Titelleiste eines Fensters klicke, dann ist es eben nicht den view, den ich haben will, sondern das Fenster!

Wolf ist damit jedenfalls ganz sicher nicht geholfen. Ganz im Gegenteil! Das ist schade für andere Forumsteilnehmer! In der Tat!

Letztens war deine Meinung über Michael doch noch eine ganz andere?

wofür braucht das Menu die?

Für das ermitteln des Verdeckens.
Ich habe Cocoa nicht geschireben. Ich schireb auch schon, dass ich nicht weiß, welche Methdoen er genau auf den View anwendet. Deshalb werde ich es eben auch nicht in ein Fenster implementieren, weil ich nämlich dann genau die Fehlermeldungen bekomme (Method ... not implemented) die Wolf bekam. Genau deshalb lass ich einen Trick vbleiben, den ich gar nicht brauche.

Der Gedankenverlauf ging ungefähr so:

Dr Gedankengang wird eher so gewesen sein: Wenn du ein Menü in einem Fenster brauchst, dann lege doch ein View hinein. Denn jedes Fenster hat ein View.

Ist das nicht eine kausale forderung, wenn jemand eingene Funktionalität implementieren will?

Ebendt(tm)! Deshalb wundere ich mich auch, dass Michael seit 3 Threads darauf besteht, man könne ein anderes Verhalten ohne anderen code implementieren.

Das ist gerade dein Fehler. Es ist eben nicht das selbe. Denn Fenster != View und wenn ich auf die Titelleiste eines Fensters klicke, dann ist es eben nicht den view, den ich haben will, sondern das Fenster!

Die Titelleiste eines Fensters _ist_ ein View. Übrigens klappt das nur, wenn du wirklich auf den Titel klickst. Und was ist da? Lass mich raten! Ein NestTextField? Und wovon ist NSTextField abgeleitet?

Letztens war deine Meinung über Michael doch noch eine ganz andere?

Wolf hat glücklicherweise bereits vor 129837918237 Beiträgen erkannt, dass man es in einem View implementiert. Geh mal auf Seite 1 dieses Threads.
Verwunderlich ist nur, dass es Michael genauso implementiert hat und dennoch darauf besteht es anders zu machen. Das kann ich wirklich nicht nachvollziehen.

Aber ansonsten hat hier Michael schon sehr viel Hifle gegeben und meine grundsätzliche Meinung zu ihm hat sich nicht geändert.

Original von Tom9811
Deshalb wundere ich mich auch, dass Michael seit 3 Threads darauf besteht, man könne ein anderes Verhalten ohne anderen code implementieren.

Unterstell mir bitte nicht etwas, was ich nie gesagt habe!

Michael

Original von Tom9811

wofür braucht das Menu die?

Für das ermitteln des Verdeckens.

Weil ein Menu auch von anderen Sachen überdeckt wird. Oder überdeckt es anderes anders? Nee, ware mal. Ein Menu liget dich immer ganz oben und es gibt nur genau ein offenes Menu zu einem Zeitpunkt... Wie soll sich da was überdecken?

Ich habe Cocoa nicht geschireben. Ich schireb auch schon, dass ich nicht weiß, welche Methdoen er genau auf den View anwendet. Deshalb werde ich es eben auch nicht in ein Fenster implementieren, weil ich nämlich dann genau die Fehlermeldungen bekomme (Method ... not implemented) die Wolf bekam. Genau deshalb lass ich einen Trick vbleiben, den ich gar nicht brauche.

Wenn du's genau wissen willst, dann schau einfach mal mit shark rein. Da bekommst du die ganzen Aufrufe suaber raus. Oder du macht nen methodSizzle oder post deine eigene klass rein oder suchst mit class-dump nach versteckten bösen hinterhältigen methoden.

Dr Gedankengang wird eher so gewesen sein: Wenn du ein Menü in einem Fenster brauchst, dann lege doch ein View hinein. Denn jedes Fenster hat ein View.

Du verstehst es nicht. Aber vielleicht ist das bei dir ja so ne blockade...

Die Titelleiste eines Fensters _ist_ ein View. Übrigens klappt das nur, wenn du wirklich auf den Titel klickst. Und was ist da? Lass mich raten! Ein NestTextField? Und wovon ist NSTextField abgeleitet?

kannst du das beweisen? hast du zugriffsmethoden?

Verwunderlich ist nur, dass es Michael genauso implementiert hat und dennoch darauf besteht es anders zu machen. Das kann ich wirklich nicht nachvollziehen.

Tut er nicht.

Aber mi ist das jetzt reichlich egal. Unwissenheit ist ein Segen. In dem Sinne : Prost.

Weil ein Menu auch von anderen Sachen überdeckt wird. Oder überdeckt es anderes anders? Nee, ware mal. Ein Menu liget dich immer ganz oben und es gibt nur genau ein offenes Menu zu einem Zeitpunkt... Wie soll sich da was überdecken?

atsächlich? Wenn du im Hintergrund ein Kontext-Menu aufmachst? Und wenn dann schon eines offen ist? Dann liegen die beide übereinander? Das erinnert immerhin an ein Bild von Escher.

Wenn du's genau wissen willst, dann schau einfach mal mit shark rein. Da bekommst du die ganzen Aufrufe suaber raus. Oder du macht nen methodSizzle oder post deine eigene klass rein oder suchst mit class-dump nach versteckten bösen hinterhältigen methoden.

Ich will es nicht genau wissen, weil ich es nicht benötige. Ich lese ach die Doku und muss keinen Class-Dump machen. Derlei überlasse ich den Exception-Technikern, die glauben, ein Class-Dump würde ihnen etwas für die Funktionsweise er Methoden verlangen.Vielleicht liegt es ja auch daran, dass meine Software keine Exceptions wirft.

Mich wundert allerdings, dass diejenigen, die dieses Vorgehen propagiert haben, es offenbar nicht genau wissen. Frei nach dem Motto: Mach das doch so. Ach, dann bekommst du eine Exception? Hmm, dann probiere nochmal jenes und dieses. Ach, ein NSWindow ist kein View? Na gut, dann halten wir uns nicht an die Parameter. Funktioniert ja (Wie meine Lösung gerade funktinierte,m die eine Exception warf.) Na, nicht schlimm, wenigstens hat Tom Ahnung und kann ja mal nachforschen, was an meiner Lösung nicht funktioniert.
Sorry, auch meine Zeit ist begrenzt. Ein bisschen musst du schon selbst Doku lesen, Max.

kannst du das beweisen? hast du zugriffsmethoden?

1. Das funlktioniert nur auf dem Titel. Komisch nicht?
2. Nicht ich muss es beweisen, sondern derjenige, der behauptet, dort sei kein View. Das war nicht ich. Ich habe davon gar nicht erst angefangen, weil das für mich eine Selbstverständlichkeit ist.
3. Ist es schon komisch, wenn ganu viele Dinge in der Titelbar gezeichnet werden so ohne View.
4. lockFocus exitiert nur für einen NSView und einen NSImage. Das ist aber kein Problem. Denn daraus, dass -lockFocus(NSWindow) nicht dokumentiert ist, darf man keinesfalls folgeern, dass Cocoa offenabr nur in Views und Images zeichnen will! Nein, nein, aus dem Fehlen kann man folgen, ex silentio sozusagen, dass sie Methode schon da ist. Sonst würde da ja stehen, dass sie nicht existiert Ach, er wirft eine Exception, wenn man das versucht? Das ist egal. Wir sind hier ohnehin gerade bei Max, dem Exception-Techniker. Aber ach das ist egal. Wir überladen uns einfach Cocoa gleich ganz komplett und programmieren uns die Maxoa.Am besten wir machen es so, dass wir uns einen eigenen Bildschirm reservieren und den über den uns nicht gehörenden Bildschirm mappen. Dann können wir auch so malen, wie es uns beliebt. Eine Lösung, die an Eleganz kaum zu überbieten ist!
Wozu auch in einem View zeichen, tsss, was für ein Blödsinn, wir haben doch ein Fenster!!!!98!!!!!!!! Das hat bekanntlich keine Views. (BTW: GEHEIMtipp: -contentView(NSWindow) ist nur ein Fake von den Illuminaten. Aus der Existenz der Beschreibung in der Doku können wir nämlich folgern, dass es die Methode _nicht_ giubt. Ist ja logisch!!!!98!!!!!!!)

Tut er nicht.
Aber mi ist das jetzt reichlich egal. Unwissenheit ist ein Segen.

Er hat es als Kontext-Menü eines Views implementiert.
Er propagiert hier die Implementierung im Fenster.
Du hast hier zahlreiche Vorschläge gemacht, von denen du nicht weißt, ob sie funktionieren, sie teilweise sogar erkennbar nicht funktionieren. Hinweis: Ein Exception ist kein Zeichen für das Funktionieren.

In dem Sinne : Prost.

Eieieieieiei, ich häte mir gleich bei dem Vorschlag, sendEvent zu überladen denken können, dass du nicht nüchtern bist. Gut, dass das keiner so macht! Allerdings deutet der jetzige Beitrag auf ein dauerhaftes Problem hin. Zeichnen außerhalb Views auf dem System-Bildschirm ist schon ein starkes Stück. Darauf kann man nüchtern eigentlich nicht kommen.
BTW: Was mir gerade so auffällt: -lockFocusOnRepresentation(NSImage) sagt auch, dass man als Parameter nil übergeben kann.

Original von Tom9811
Er propagiert hier die Implementierung im Fenster.

Ich habe Dich bereits schon einmal gebeten, mir nicht etwas zu unterstellen, was ich nicht gesagt habe. Dafür, dass Du offenbar nicht bemerkt hast, dass es schon länger nicht mehr um eine Lösung für das ursprüngliche Problem geht, sondern um die Erklärung, warum der erste Ansatz (-rightMouseDown: in NSWindow zu überschreiben) nicht funktioniert hat, kann ich nichts. Ich kann auch nichts dafür, dass Du, sämtliche Tatsachen ignorierend, die Erklärung nicht verstehen willst und als falsch abstempelst.

Michael

(Das war jetzt auch wirklich der letzte Diskussionsbeitrag mit Dir)

Das klang hier aber ganz anders:

(Soviel zu Unterstellungen.)

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.

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 [Kontext bedeutet hier der Kontext eines Views.] machbar sind.

Schon mal an Popup-Menüs ganz ohne Fenster gedacht? Zum Beispiel für kleine Helferprogramme, die im Hintergrund laufen und per globalen Tastatur-Shortcut ein Popup-Menü präsentieren.

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?

[Hervorhebungen und Anmerkungen durch mich.

letzter Beitrag, mir reichts.

Original von Tom9811Tatsächlich? Wenn du im Hintergrund ein Kontext-Menu aufmachst? Und wenn dann schon eines offen ist? Dann liegen die beide übereinander? Das erinnert immerhin an ein Bild von Escher.

warum sollte ich im hintergrund ein kontext menü aufmachen? Und wei soll das bitte gehen, wenn der user bereits eins offen hat? (so mal von der Nutzung aus gesehn) Denken!

Ich will es nicht genau wissen, weil ich es nicht benötige. Ich lese ach die Doku und muss keinen Class-Dump machen. Derlei überlasse ich den Exception-Technikern, die glauben, ein Class-Dump würde ihnen etwas für die Funktionsweise er Methoden verlangen.Vielleicht liegt es ja auch daran, dass meine Software keine Exceptions wirft.

Hast du jemals meine Software genutzt. Hab ich hier irgendwo auch nur einmal das Wort Exception erwähnt? Warum sollte die Methode einen Exception werfen? Wenn eine Emthode ne exception wirft, dann stimmt was nicht. Aber vielleicht is es ja so eine Angewohnheit von dir, allen Leuten Sachen in den Mund zu legen die sie nicht gesagt haben...

Mich wundert allerdings, dass diejenigen, die dieses Vorgehen propagiert haben, es offenbar nicht genau wissen. Frei nach dem Motto: Mach das doch so. Ach, dann bekommst du eine Exception?

s.o.

Hmm, dann probiere nochmal jenes und dieses. Ach, ein NSWindow ist kein View?

Diesen Unterschied hab ich hier irgendwo hervoergehoben. Aber du hast es wohl überlesen. Passiert halt...

Na gut, dann halten wir uns nicht an die Parameter. Funktioniert ja (Wie meine Lösung gerade funktinierte,m die eine Exception warf.)

s.o.

Na, nicht schlimm, wenigstens hat Tom Ahnung

Die Gerüchteküche brodelt.

und kann ja mal nachforschen, was an meiner Lösung nicht funktioniert.

hab ich gesagt, dass sie nicht funktioniert? Also bitte.

Sorry, auch meine Zeit ist begrenzt. Ein bisschen musst du schon selbst Doku lesen, Max.

kein Kommentar. So ne arroganz muss ich mir nicht geben.

1. Das funlktioniert nur auf dem Titel. Komisch nicht?

find ich nicht. Es ist nämlich der einzige Bereich, wo's logisch ist

2. Nicht ich muss es beweisen, sondern derjenige, der behauptet, dort sei kein View. Das war nicht ich. Ich habe davon gar nicht erst angefangen, weil das für mich eine Selbstverständlichkeit ist.

Nein, du hast behauptet, dass es einen gibt. Du bist in der pflicht. Als Anwalt solltest du das wissen.

3. Ist es schon komisch, wenn ganu viele Dinge in der Titelbar gezeichnet werden so ohne View.

Ein view ist heigh-level. ich würde einfahc mal behaupten wollen, dass eine titelbar überhaupt nichts mit nem view zu tun hat und deshalb aus dem low-level drawing kommt....

4. lockFocus exitiert nur für einen NSView und einen NSImage.

und wi wird dann das zeug vom view hingezeichnet? das kommt in den Buffer des fensters. Und den fragt dann das system ab. -> kein Bedarf, ein lock focus zu machen

Das ist aber kein Problem. Denn daraus, dass -lockFocus(NSWindow) nicht dokumentiert ist, darf man keinesfalls folgeern, dass Cocoa offenabr nur in Views und Images zeichnen will!

mal davon abgesehen, dass es so eine funktion nicht gibt und wir sie auch nicht brauchen, hat NSWindow nur diese lock-funktionen:

[Inhaltsloses Geschafel]

Wie originell. Du solltest kinderbücher schreiben!

In dem Sinne : Prost.

Eieieieieiei, ich häte mir gleich bei dem Vorschlag, sendEvent zu überladen denken können, dass du nicht nüchtern bist. Gut, dass das keiner so macht! Allerdings deutet der jetzige Beitrag auf ein dauerhaftes Problem hin. Zeichnen außerhalb Views auf dem System-Bildschirm ist schon ein starkes Stück. Darauf kann man nüchtern eigentlich nicht kommen.[/quote]
Nur als kurzinfo: ich hab nen Orangensaft getrunken. Aber du hast dir das gleich wieder zurechgebogen, um mir wieder irgend etwas zu unterstellen. War ein einfacher Test und du bist drauf raingefallen. Arm, sehr arm.

BTW: Was mir gerade so auffällt: -lockFocusOnRepresentation(NSImage) sagt auch, dass man als Parameter nil übergeben kann.

und was sagt mir das?

warum sollte ich im hintergrund ein kontext menü aufmachen? Und wei soll das bitte gehen, wenn der user bereits eins offen hat? (so mal von der Nutzung aus gesehn) Denken!

Richtig und zunächst lesen. Es war nicht meine Idee, PopUps aus dem Nichts auftauchen zu lassen. Wahrlich nicht!

ast du jemals meine Software genutzt. Hab ich hier irgendwo auch nur einmal das Wort Exception erwähnt? Warum sollte die Methode einen Exception werfen? Wenn eine Emthode ne exception wirft, dann stimmt was nicht. Aber vielleicht is es ja so eine Angewohnheit von dir, allen Leuten Sachen in den Mund zu legen die sie nicht gesagt haben...

(Zitiert nach Tsunamix).
Übrigens habe ich nicht behauptet, dass ud das gesagt hast. Bitte lege mir keine Wörter in den Mund.

Diesen Unterschied hab ich hier irgendwo hervoergehoben. Aber du hast es wohl überlesen. Passiert halt...

Tatsächlich? Zeig mal wann und wo!

hab ich gesagt, dass sie nicht funktioniert? Also bitte.

Das habe ich auch nicht behauptet. Also bitte!

find ich nicht. Es ist nämlich der einzige Bereich, wo's logisch ist

Und wie ist der "Bereich" wohl implementiert? Der macht da besimmt eine Berechnung der Glyphs ohne View!

Nein, du hast behauptet, dass es einen gibt. Du bist in der pflicht. Als Anwalt solltest du das wissen.

Nope, die Idee stammt von Michael, der meinte, man könne das ja auch da machen ohne Views. Darauf habe ich erwidert, dass da sicher ien View ist.

Aber lass ues uns doch so machen: Wir wetten einfach um 1.000,00 €, ok?

Ein view ist heigh-level. ich würde einfahc mal behaupten wollen, dass eine titelbar überhaupt nichts mit nem view zu tun hat und deshalb aus dem low-level drawing kommt....

Ich habekeinen blassen Schimmer, was du damit meinst. Ist da ein View oder nicht?

und wi wird dann das zeug vom view hingezeichnet? das kommt in den Buffer des fensters. Und den fragt dann das system ab. -> kein Bedarf, ein lock focus zu machen

Ah, der implementiert die ganzen Routinen zum Zeichen nochmal neu.

mal davon abgesehen, dass es so eine funktion nicht gibt

Ach nein, tatsächlich?

und wir sie auch nicht brauchen, hat NSWindow nur diese lock-funktionen:

Du siehst mich bass erstaunt!!!!!98!!!!!!

Nur als kurzinfo: ich hab nen Orangensaft getrunken. Aber du hast dir das gleich wieder zurechgebogen, um mir wieder irgend etwas zu unterstellen. War ein einfacher Test und du bist drauf raingefallen. Arm, sehr arm.

Genau, und weil das unsere erste Begegnung hier ist und du dabei noch nie etwas getrunken hast, hast du das bisher auch erwähnt.

und was sagt mir das?

*seufz* Dass die Doku üblicherweise darauf hinweist, wenn nil sinnvoll ist.

Ich wollte ja eigentlich nicht mehr, aber ...

Original von Tom9811

Das klang hier aber ganz anders:

(Soviel zu Unterstellungen.)

Ok, ich habe es kapiert. Bei Deinen Worten ist bei der Deutung sämtlicher Kontext drum herum zu ignorieren, weil sich sonst ein anderer Sinn ergeben könnte. Jeder Beitrag von Dir steht für sich ganz alleine da und hat mit voher Gesagtem nichts zu tun.

Original von Tom9811
[eine Menge aus dem Kontext herausgerissene Zitate]

Im Gegensatz zu Dir schreibe ich Antworten und beziehe mich dabei auf zuvor Gesagtes.

Michael

Nur um dir noch einmal die Sinnlosifgkeit deiner "Argumentation" vorzuführen:

Original von Tom9811
Tatsächlich? Zeig mal wann und wo!

Original von M.A.X weiter oben
Denn Fenster != View

Ich hab nur gerade was gefunden, was ich noch ergängen möchte:

In der Titelbar eines Fensters ist wirklich ein NSView, aber in einer sehr tiefen Vererbung:



Allerdings wurde in den subclasses so jede auch nur denkbare methode überschrieben, dass man davon ausgehen kann, dass der NSView hier nur noch als abstrakte Superklasse agiert, damit die NSButtons oben links im Fenster auch ja da rein zeichnen. Und das sind "echte" NSButtons, was ich auch für sehr interessant halte

Max

Selbstevrständlich ist das ein View. Es wäre auch offensichtlicher Blödsinn, etwas außerhalb eines Views zu malen. Was das mit Vererbung zu tun hat, ist mir jetzt allerdings nicht klar.

Dass die Knöppkes in der Titelbar ebenfalls Buttons sind, überrascht mich nicht. Es wäre auch offensichtlicher Blödinn, ein Button das zweite Mal zu programmieren, wenn in Cocoa schon einer herumfliegt.