Auf Schließen eines Fenster NSWindowControllers reagieren

  • Auf Schließen eines Fenster NSWindowControllers reagieren

    Hi zusammen,
    ich habe mir für mein Einstellungs-Fenster ein NSWindowController gesubclasst (mit Hilfe von diesem Control: mere-mortal-software.com/blog/details.php?d=2007-03-11). Alle Einstellungen werden über Bindings in die Shares User Defaults geschrieben.
    Soweit so gut, nun möchte ich jedoch nach dem Schließen des Einstellungen-Fensters, dass einige Variablen sich die Daten neu holen usw. Problem ist jedoch, dass ich nicht weiß, wann das Fenster geschlossen wird. Folgendes funktioniert natürlich nicht, zeigt aber was ich eigentlich vor habe:

    Quellcode

    1. - (IBAction)openPreferencesWindow:(id)sender
    2. {
    3. [[PrefWindowController sharedPrefsWindowController] showWindow:nil];
    5. // Einstellungen setzen
    6. serverHostname = [[NSUserDefaults standardUserDefaults] valueForKey:@"ServerHostname"];
    7. serverPort = [[NSUserDefaults standardUserDefaults] integerForKey:@"ServerPort"];
    9. // Ab dafür
    10. [trackTimer fire];
    12. // Bitte auch die Fenster-Transparenz setzen
    13. [mainWindow setAlphaValue:[[NSUserDefaults standardUserDefaults] floatForKey:@"AlphaValue"]];
    14. }
    Alles anzeigen

    Ich hab in der Cocoa Referenz geguckt, aber keine Nachricht gefunden, die irgendwie verschickt wird, wenn das Fenster geschlossen wird (weder der Sender, noch die subgeclasste Klasse selber).

    Hab ich was übersehen oder gibt es da einen kleinen Trick?

    Chris

  • RE: Auf Schließen eines Fenster NSWindowControllers reagieren

    Du kannst dich
    a) selbst an die User-Defaults binden
    b) ein Delegate für das Fenster machen und dort -windowShouldClose:, -windowWillClose: implementieren
    c) auf die Notification NSWindowWillCloseNotification des Fensters hören
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Notifications ...

    du sollst diese Notification beobachten.

    In deinem Hauptcontroller:

    Quellcode

    1. [[NSNotificationCenter defaultCenter] addObserver:self
    2. selector:@selector(aktualisiereDaten:)
    3. name:@"NSUserDefaultsDidChangeNotification"
    4. object:nil];


    in dieser Methode "aktualisiereDaten:(NSObject *)object" soll die Daten gelesen werden und dem View gesetzt.
    Aus macfreakz wurde Apfelbeisser …

  • Ein Delegate "biegst du herein", indem du die Methode implementierst und eine Verbindung im IB ziehst. Das ist definitiv einfacher, jeodch -- wie bereits gesagt -- zentral, während Notifications an jeden verchickt werden, der sich dafür interessiert.

    Als Faustregel gilt, dass jede Noification auch eine Delegate-Methode hat. Umgekehrt geht das nicht, da die Should-Methoden des Delegates freilich bei Notifications nicht funktionieren können.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Original von CalganX
    Hi,
    ah, okay, stimmt. Tja, manchmal ist Cocoa/Obj-C einfacher, als man denkt. (Wenn man jedoch von Object Pascal/Delphi/C#/etc. kommt, ist das Konzept der Sprache extrem gewöhnungsbedürftig)

    Danke,
    Chris

    Musste mich mal in einem Projekt mit Object Pascal/Delphi auseinandersetzen. Fand ich auch extrem gewöhnungsbedürftig und war froh, danach wieder C schreiben zu dürfen.
    cu
    Peter

  • @macfreakz: wenn du zwischen Cocoa/Obj-C und Java noch Delphi einfügst, stimme ich dir zu. :D Wobei es auch mal interessant ist ganz "back to the roots" zurück auf die WinAPI zu gehen. Für größere Projekte ist das aber definitiv nichts.

    @WoSoft: ich denke das ist in erster Linie die Macht der Gewohnheit. Aber produktiv Anwendungen mit großem Umfang in C schreiben? Womit? Doch nicht etwa mit der MFC? Und bei der WinAPI sitzt man die meiste Zeit ja auch daran die GUI geregelt zu bekommen. Ne, danke. Zum Spielen ja, zum produktiven Einsatz nicht.

    Chris