Laden...

Spezielle .exe überwachen und auf Schließung reagieren

Erstellt von cH40zLOrd vor 15 Jahren Letzter Beitrag vor 15 Jahren 1.760 Views
C
cH40zLOrd Themenstarter:in
14 Beiträge seit 2008
vor 15 Jahren
Spezielle .exe überwachen und auf Schließung reagieren

Aloah - ich bin es noch einmal 😜

Da ich ja zur Zeit an einem Launcher arbeite und ich vor dem Start eines Spiels ein paar Daten abändern muss, welche nach Beendigung des Games wieder rückgängig gemacht werden sollten, habe ich nun mich versucht ein wenig schlau zu machen um zu sehen, welche Möglichkeiten es da gibt.

Meine erste Grundidee war ja erst einmal, dass ich jede 1 oder 2 Sekunden überprüfe, ob das Fenster noch existiert - laut Google wäre das zu CPU-Lastig, woran ich auch erst gedacht habe...

Dann habe ich ein potentiellen Code gefunden, welcher ein Prozess mit meiner Anwendung synchronisiert und mir ein Quit-Event auslöst, sobald die Anwendung geschlossen wird.

Das Problem bei diesem Code nun aber ist, dass ich ihn nicht mit .NET 3.5 compilen kann.

private System.Diagnostics.Process p;
...
 
...
 
Im Load-Event iwo ein Aufruf an Test()...
...
 
...
 
        private void Test()
        {
            p = new System.Diagnostics.Process();
            // Handle the Exited event that the Process class fires.
            this.p.Exited += new System.EventHandler(this.p_Exited);
            p.EnableRaisingEvents = true;
            p.SynchronizingObject = this;   // <-------------------- Diese Zeile meckert er mir an, genauer gesagt, das 'this'
            p.StartInfo.FileName = "notepad.exe";
            p.Start(); 
        }
 
 
Error: Cannot implicitly convert type 'MyApp.Window1' to 'System.ComponentModel.ISynchronizeInvoke'. An explicit conversion exists (are you missing a cast?)

Hat da irgendjmd eine Idee zu oder sogar schon ein funktionierenden Code ?

Viele liebe Grüße,
cH40z-Lord

T
75 Beiträge seit 2007
vor 15 Jahren

Hey cH40zLOrd,
Ich hab keine direkte Lösung zu deinem Code-Problem!
Aber wie wäre die objektorientierte Idee, eine übergeordnete Kontrollklasse zu machen.

  • Sie hat Eventhandler für den Aufruf zum Spielstart-Button des Launchers sowie für das Schließen des Spiels
  • Sie startet den darin instanzierten Launcher
  • dann wird das Spiel aufgerufen
  • beim schließen des Spiels kannst du dann den launcher wieder starten.

Das halte ich für Sinnvoll.

Viele Grüße
Till-H

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo cH40zLOrd,

dein Form muss ISynchronizeInvoke implementieren, damit du es es SynchronizingObject verwenden kannst.

herbivore

6.862 Beiträge seit 2003
vor 15 Jahren

Solche Probleme hat man nur wenn man Code kopiert und nicht versteht was er macht 🙂

Prinzipiell ist das SynchronizingObject für dein Problem völlig unerheblich, es vereinfacht nur das Eventhandling wenn deine Funktion p_Exited irgendwie mit der GUI interagieren soll. Weil durch das SynchronizingObject kann man ein Object festlegen welches Invoke und die restlichen Member von ISynchronizeInvoke' implementiert und über welches dann automatisch in den GUI Thread invoked wird, man muss sich dann nicht von Hand im EventHandler drum kümmern. Deshalb wird da oft einfach die aktuelle Form übergeben um über sie in die GUI zu invoken, deshalb einfach this, weil der Code mit absoluter Sicherheit aus nem Windows Forms Programm stammt, oder?

In WPF wird dieses Interface nicht mehr benutzt, da das Konzept leicht geändert wurde, es gibt jetzt dedizierte Dispatcher Objekte zu einem Thread über die die Zugriffe geregelt werden.

Für dich heißt das einfach, dieses Property nicht setzen und im EventHandler falls benötigt, über den Dispatcher des Windows, evtl. benötigte Zugriffe auf die GUI invoken. Wenn du wie in deinem Beispiel die Überwachung eh im GUI Thread ausführst(bei dir ja im Load Event), dann ist gar kein invoken nötig.

Baka wa shinanakya naoranai.

Mein XING Profil.