OnFinish --> FreeAndNil --> Exception

[berens]

Code:

I.d.R. wird es krachen, da beim "Rückabarbeiten" des Event-Kette irgendwo noch auf Eigenschaften des schon freigegebenen Objektes zugegriffen wird.

Ja, das ist richtig, ich hoffe ich konnte im ersten Beitrag vermitteln, dass ich selbst (schmerzhaft) zu dieser Erkenntnis gelangt bin.

Die Frage ist halt: Wie macht man es richtig?

Weil wenn man nicht Ereignis-bezogen freigeben kann ("Ich bin fertig - lösch mich") muss man ja in zeitlichen Intervallen prüfen "Wenn fertig, dann löschen". Das muss doch auch anders gehen, oder irre ich mich?

Edit:
Ich habe es jetzt tatsächlich so "gelöst", dass ClientSocket1Disconnect einen Timer startet, der nach 1 ms das NotifyFinish aufruft. Gut - Nicht Gut? Kann es sein, dass innerhalb der 1 ms der ClientSocket immer noch nicht fertig "verarbeitet" ist, obwohl nach dem Stellen des Timers keine Programmierzeile mehr ist, und es deshalb unerwartete Probleme gibt?

[freimatz]

Timer sind in 99% der Fälle nicht gut. in der Regel sollte der, der eine Klasse erzeugt diese auch wieder freigeben. Kannst du nicht "der" ein Event schicken dass diese das macht?

[berens]

Zitat:

Kannst du nicht "der" ein Event schicken dass diese das macht?

Ja, aber wann und wie löse ich dieses Event aus? Das ist ja die Kernfrage.

Bei ClientSocket1Disconnect kann ich das ja nicht tun. Woher weiß ich denn, wann das Event ausgelöst werden soll, wenn nicht über dieses Ereignis?

Das einzige, ansatzweise "professionelle" Verfahren was ich mir hierfür vorstellen könnte, ist, dass SendFinished NICHT FreeAndNil aufruft, sondern den Sender (cs) merkt (z.B. in einer ComponentList speichern). Eine -wie auch immer aufzurufende- (wieder das Kernproblem!) Prozedur schaut nach, ob in der ComponentList Einträge stehen und löscht diese Komponente dann mit FreeAndNil. Alternativ bekommt TFoo einfach eine Boolean-Variable, ob Fertig oder nicht, und TForm2 prüft dann halt die Boolean-Variable, und löscht die Komponente dann. Trotzdem muss diese "Löschroutine" von TForm2 über einen Timer oder sporadisch im Rahmen anderer Prozeduren aufgerufen werden, damit die Komponenten TFoo freigegeben werden können. Wird wohl so klappen, aber ob das dem Konzept der Asynchronen Programmierung entspricht (ernstgemeinte Frage)?

[ChrisE]

Hallo,

also prinzipiell läßt sich das über mehrere Ansätze lösen.

1. Ansatz - dem Objekt sagen es soll sich später freigeben
--> Das Objeckt soll sich abarbeiten und den selber Freigeben. Aber nur wenn man es dazu auffordert (DoTerminate := TRUE

2. Ansatz - entkoppplung "der Botschaft" vom Objekt-Kontext
a) PostMessage mit WM_MEINE_MESSAGE an z.B. Form

Delphi-Quellcode:

const WM_MEINE_MESSAGE = WM_USER +1;
//...
TForm2.
procedure WMMeineMessage(var Message: TMessage);message WM_MEINE_MESSAGE;
//...

b) Anonymer Thread

Delphi-Quellcode:

procedure ExecuteInAnonymThread(AThreadProc: TProc; ADoSyncronized: Boolean; ADelay: Int64);
begin
  TThread.CreateAnonymousThread(
    procedure
    begin
      Sleep(ADelay);
      if ADoSyncronized then
      begin
        TThread.Synchronize(nil,
          procedure
          begin
            AThreadProc;
          end);
      end else begin
        AThreadProc;
      end;
    end).Start;
end;

Vielleicht bringt dich das ja weiter

Gruß, Chris

[Rollo62]

Ich würde mir mal anschauen wie das TMessage und TMessageManager gelöst haben.

Die benutze ich an zig Stellen, und das arbeitet sehr zuverlässig mit und ohne Threads.

Rollo

[QuickAndDirty]

Delphi-Quellcode:

Procedure QueueMethod(aThreadMethod:TThreadMethod);
Begin
      // Abgeschaut aus UNIT FMX.FORMS
      // procedure ReleaseForm(const AForm: TCommonCustomForm);
      // Wir müssen das immer so machen wie die das dort auch machen.
      // Unter der Annahme dass die FMX Bibliotheken fehlerfrei sind....

      {$IFDEF ANDRODID}
      TThread.CreateAnonymousThread(
        Procedure
        Begin
          TThread.CurrentThread.Queue(nil,AthreadMethod);
        end;
      );
      {$ELSE}
       TThread.CurrentThread.ForceQueue(nil,aThreadMethod);
      {$ENDIF}
end;

TThread.CurrentThread.ForceQueue(nil,aThreadMethod );
Macht unter Windows im Hauptthread, dass die Methode erst nach dem "abspielen" aller anderen Messages aufgerufen wird...
Dieser Mechanismus reagiert also evtl. unerwünscht auf Application.processmessages...
Denn innerhalb dieses Aufrufs würde die Methode auch ausgeführt...