Hi!

Ich benutze einen Thread, der im Prinzip simpel aussieht und folgendes macht:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TMyThread.Execute;
begin

  CoInitialize;

  while ... do

    if Terminated then
    begin
      CoUninitialize;
      Exit;
    end;

    Arbeite(...);
    // Hier wird gearbeitet, u.a. Websites abgerufen mit IXMLHTTPRequest bzw. CoXMLHTTP (muss zugeben, dass ich den Code zusammengesucht habe und nicht wirklich was davon verstehe)

  end;

  CoUninitialize;

end;

Nun möchte ich - falls der Benutzer das Hauptfenster schließt - gerne den Thread ohne Rücksicht auf Verluste abbrechen und das Programm ohne Verzögerung schließen.

Das war bisher so gelöst:

markieren

Delphi-Quellcode:

procedure TMainForm.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin

  ...

  MyThread.Terminate; //***
  MyThread.WaitFor; //***
  FreeAndNil(MyThread);

end;

Mit der obigen Lösung kommt es aber vor, dass das Hauptfenster dann für einige Zeit (bis zu ~30s) einfriert, bevor es geschlossen wird.

Wenn ich die beiden mit //*** gekennzeichenten Zeilen weglasse, dann wird das Programm ohne Fehlermeldung wie gewünscht sofort geschlossen. Allerdings wird dabei dann nicht mehr CoUninitialize aufgerufen. Spielt das denn überhaupt noch eine Rolle? Schließlich wird mein Prozess ja ohnehin gekillt...

Schonmal Danke für eure Hilfe!
Robert

Nach http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
zu deuten, kann es schonmal etwas länger dauern. Du kannst aber auch einfach dein eigenes WaitFor schreiben, wie ich es mit
http://jwscldoc.delphi-jedi.net/TJwT...D@Boolean.html
gemacht habe.

markieren

Delphi-Quellcode:

MyThread.WaitFor;
FreeAndNil(MyThread);

Weglassen und den Thread sich selber freigeben lassen? (FreeOnTerminate)

Genial einfach - einfach genial!

Vielen Dank für den "Denkanschubser", so funktionierts wie gewünscht!

Beste Grüße und Danke euch beiden!
Robert

PS:
Nur mal aus Interesse... Würde es tatsächlich "schaden", wenn ein Programm beendet wird, ohne vorher das nötige CoUninitialize aufzurufen?

Sagen wir es mal so: Etwas aufräumen kann nicht schaden.

Selbst wenn windows vieles frei git, wenn die App geschlossen wird, kann man ja dennoch selber seinen Mist wegräumen, so wie man ja auch wärend der Programmlaufzeit alles fein säuberlich aufräumt.


WinNT züchtet Schlampen heran.

Das sehe ich prinzipiell genauso, himitsu. Aber wenn es einem ausnahmsweise mal das Leben wesentlich leichter macht, kann man ja mal im Einzelfall drauf verzichten. Deshalb noch ein letzter Versuch :

Wird die COM library beim Beenden des Anwendungsprozesses automatisch freigegeben, sodass es nicht nötig ist, CoUninitialize am Ende des Programms aufzurufen?

Beste Grüße!
Robert

Wenn ich bislang CoInitalize /CoUninitialize gebraucht habe, habe ich das im initialization und finalization-Abschnitt der Unit untergebracht.

Das geht aber leider nicht, wenn man auf die COM library innerhalb eines separaten Threads zugreifen möchte, da dann das CoInitialize (und CoUninitialize) vom betreffenden Thread aufgerufen werden muss (habe ich hier gelernt: http://www.delphipraxis.net/162151-i...coxmlhttp.html).

Gruß!
Robert

Zitat von Rob09:

Wird die COM library beim Beenden des Anwendungsprozesses automatisch freigegeben, sodass es nicht nötig ist, CoUninitialize am Ende des Programms aufzurufen?

Ja, wenn deine App wirklich beendet wurde, räumt das OS alles und jedes auf, ausgenommen natürlich Ring0 Treiber, die aus dem USER Mode "behandelt werden".

lg.

Zitat von Astat:

Zitat von Rob09:

Wird die COM library beim Beenden des Anwendungsprozesses automatisch freigegeben, sodass es nicht nötig ist, CoUninitialize am Ende des Programms aufzurufen?

Ja, wenn deine App wirklich beendet wurde, räumt das OS alles und jedes auf, ausgenommen natürlich Ring0 Treiber, die aus dem USER Mode "behandelt werden".

lg.

Damit sind aber nicht alle COM-spezifischen Aktivitäten abgedeckt. Laut MSDN bewirkt CoUninitialize:

Zitat:

Closes the COM library on the current thread, unloads all DLLs loaded by the thread, frees any other resources that the thread maintains, and forces all RPC connections on the thread to close.

Das mindeste, was ich mir hier vorstellen kann, ist, daß die Referenzzähler einiger DLLs durcheinandergeraten. Die wirklich schlimmen Sachen kann ich mir aber wahrscheinlich noch gar nicht vorstellen.

Nehmen wir aber mal an, man könnte CoUninitialize einfach weglassen. Wer garantiert denn, daß das beim nächsten Windows-Update oder bei der nächsten Windows-Version auch so bleibt? MS wird dir sicher nicht gesondert mitteilen, daß du CoUninitialize dann jetzt aber wirklich aufrufen musst.