Laden...

WPF Window "zerstören"

Erstellt von Fr3dd1 vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.195 Views
F
Fr3dd1 Themenstarter:in
106 Beiträge seit 2010
vor 13 Jahren
WPF Window "zerstören"

Hallo zusammen,

aufgrund der Tatsache, dass sich eines meiner WPF Windows in meiner Anwendung nicht beendet, schließt sich meine ganze Anwendung nicht mehr.

Ich Suche jetzt eine Lösung, wie ich das entsprechende Window schließen kann. Das Problem an der ganzen Sache ist folgendes:

Das Closing Event des betroffenen Windiwos löst eine Methode aus, die das Window versteckt (hide()) und dann e.cancel = true setzt. Dadurch wird der Closing Vorgang abgebrochen. Dementsprechend kann ich nicht die Methode Close() von Window benutzten. Weiterhin ist das Window selbst auch nicht von mir sondern aus einem externem Projekt geladen wo ich keine Veränderungen vornehmen kann.

Ich hoffe hier hat jemand einen Rat für mich.

Gruß Fr3dd1

L
862 Beiträge seit 2006
vor 13 Jahren

Vielleicht hilft es dir wenn du in deiner App.xaml den ShutDownMode so einstellst dass deine Anwendung sich mit dem Hauptfenster beendet.

F
Fr3dd1 Themenstarter:in
106 Beiträge seit 2010
vor 13 Jahren

Mein Anwendung kein Anwendung sondern eine Libray (habe dementsprechend keine App.xaml), vergessen zu schreiben.

1.378 Beiträge seit 2006
vor 13 Jahren

Keine anzuratende Variante und auch viel zu umständlich, trotzdem wollt ichs erwähnen:

Du könntest dein Fenster aus deiner externen Assembly in eine eigene AppDomain laden, die du dann bei nicht verwenden am Ende zerstörst. (Brechstangenvorgehen) 😃

Lg XXX

PS: Ich sehe keine Möglichkeit ein Fenster sauber zu schließen wenn es sich nicht schließen lassen will. (Was hat sich der entsprechende Entwickler dabei gedacht?)

Gelöschter Account
vor 13 Jahren

Du willst als DLL die Hauptanwendung abschießen? Das ist ... FALSCH.

Es geht, indem du Process.Kill aufrufst aber das Vorgehen ist äußerst Schadhaft.

L
862 Beiträge seit 2006
vor 13 Jahren

Also wenn ich dich richtig verstanden habe benutzt eine Fremdanwendung deine Library. In dieser Fremdanwendung ist ein Bug der dazu führt dass sich die Anwendung nicht beenden lässt. Und nun möchtest du in deiner Library diesen Bug beheben.

Das lässt sich so nicht sauber lösen. Wenn sich die Anwendung nicht sauber beendet dann ist das ein Problem eben dieser Anwendung. Da kannst du in deiner Library nicht viel machen. Ich würde dir raten Kontakt mit dem Entwickler dieser Anwendung aufzunehmen damit der Fehler dort beseitigt wird wo er auftritt.

Sollte das (aus welchen Gründen auch immer) nicht möglich sein kannst du folgendes Versuchen:

Greife über Application.Current auf die Anwendung zu und versuche über diesen Weg den Shutdown-Mode zu setzen.
Oder versuche die Anwendungsassembly über den .NET-Reflektor zu analysieren. Es gibt für den Reflector ein Plug-In names Reflexil mit dem du die Assembly auch verändern kannst. Evtl. kannst du damit den Bug selbst beheben. Das ist aber alles ein Hack.

F
Fr3dd1 Themenstarter:in
106 Beiträge seit 2010
vor 13 Jahren

Ich glaube ich habe mich falsch ausgedrückt.

Eine Fremdanwendung ruft meine DLL auf. Ich rufe dann eine weitere DLL auf, aus dieser kommt das entsprechende Fenster.

Ursprünglich war es nicht gedacht, das gemeinte Window auszulagern, da wir das Window aber in mehreren Anwendungen gebrauchen können, wurde es im Nachhinein ausgelagert, deswegen dieser "Bug".

U
1.688 Beiträge seit 2007
vor 13 Jahren

Hallo,

füge dem "Closing"-Ereignis einen weiteren Handler hinzu und setze in diesem e.Cancel auf false.
Nichtsdestotrotz ist das hässlich...

F
Fr3dd1 Themenstarter:in
106 Beiträge seit 2010
vor 13 Jahren

Die Vorgehensweise von ujr funktioniert. Kann ich denn sicher sein, dass die Handler immer in der richtigen Reinfolge durchgangen werden? Wenn "meiner" zuerst startet, wird der Wert ja anschließend wieder überschrieben.

1.378 Beiträge seit 2006
vor 13 Jahren

Ohne fundiertes Wissen würde ich behaupten, dass sie immer der Reihenfolge durchlaufen werden, wie sie hinzugefügt wurden. Wenn du also der letzte warst der einen Eventhandler hinzugefügt hat, wirst du auch der letzte sein der aufgerufen wird.

Lg XXX

//EDIT: Multicast Delegate Internals bestätigt das in etwa unter "Sequential Invocation".