Synchronize mit Argumenten

[Viktorii]

Moin.

Erstmal habe ich schon gelesen, dass das was ich im Titel geschrieben habe nicht zu gehen scheint.

Mal ein Beispiel für mein Problem: Ich habe in einem Thread in dem z.B. irgendwelche Fehler auftreten können. Jetzt möchte ich meinem Hauptthread je nach aufgetretenem Fehler verschiedene Strings über geben.

Soweit bin ich schon:

Delphi-Quellcode:

type
  TInstError = procedure(const Content: String) of object;
 
  TMyOwnThread = class(TThread)
  private
    FInstError: TInstError;
    procedure SyncError;
  public
    property InstError: TInstError read FInstError write FInstError;
  end;
 
implementation
 
procedure TMyOwnThread.SyncError;
begin
  if Assigned(FInstError)
    then FInstError('ErrorString');
end;
 
procedure TMyOwnThread.Execute;
begin
  ...
  // Error 1
  Synchronize(SyncError);
  ...
  // Error 2
  Synchronize(SyncError);
  ...
  // Error 3
  Synchronize(SyncError);
  
  usw.
end;


procedure Form1.InstError(const Content: String);
begin
  RichEditError.Lines.Add(Content);
end;

So müsste ich aber für jeden Fehler einen eigene Methode erstellen welche ich mit Synchronize aufrufe.

Ich finde es schon lästig, dass ich überhaupt eine zusätzlich Methode dafür brauche. Das fördert nicht gerade die Übersichtlichkeit.

Aber wenn ich für jeden String ne eigene Methode brauch werd' ich ja bekloppt

Wie kann ich das eleganter lösen?

Vielen Dank

[DeddyH]

Spendier doch dem Thread ein privates Stringfeld, in das Du die Fehlermeldung schreibst. Dieses übergibst Du dann mittels FInstError.

[edit] *Hehe* schneller [/edit]

[Bummi]

Delphi-Quellcode:

procedure TMyOwnThread.SyncError;
begin
  if Assigned(FInstError)
    then FInstError(FError);
end;
 
procedure TMyOwnThread.Execute;
begin
  ...
  // Error 1
  FError := 'Error 1' ;
  Synchronize;
  ...
  // Error 2
  FError := 'Error 2' ;
  Synchronize;
  
  usw.
end;

[Sir Rufo]

Tja, das ist mit der Delphi-Version blöde ... bei den neueren Versionen macht man das ganz charmant über Anonyme Methoden.

Aber so sollte es auch charmant gehen:

Delphi-Quellcode:

type
  TInstError = procedure(const Content: String) of object;
 
  TMyOwnThread = class(TThread)
  private
    FInstError: TInstError;
    // procedure SyncError; @DeddyH: logisch muss die hier raus :o)
    CallError( const Content : string );
  public
    property InstError: TInstError read FInstError write FInstError;
  end;
 
implementation

procedure TMyOwnThread.CallError( const Content : string );
procedure SyncError;
begin
  if Assigned( FInstError )
    then FInstError( Content );
end;
begin
  Synchronize( SyncError );
end;
 
procedure TMyOwnThread.Execute;
begin
  ...
  // Error 1
  CallError( 'Fehler 1' );
  ...
  // Error 2
  CallError( 'Fehler 2' );
  ...
  // Error 3
  CallError( 'Fehler 3' );
  
  usw.
end;


procedure Form1.InstError(const Content: String);
begin
  RichEditError.Lines.Add(Content);
end;

[wicht]

Sir Rufo, das ist super!
Ich habe nie daran gedacht, das mit 'Nested'-Methoden zu machen, falls das so heißt. Habe immer 2 direkt in die Klasse gebaut und das fand ich auch immer sehr unschön.

Dankeschön

[DeddyH]

Müsste die Deklaration von SyncError dann aber nicht aus dem private-Abschnitt verschwinden?

[Sir Rufo]

Zitat von wicht:

Sir Rufo, das ist super!
Ich habe nie daran gedacht, das mit 'Nested'-Methoden zu machen, falls das so heißt. Habe immer 2 direkt in die Klasse gebaut und das fand ich auch immer sehr unschön.

Dankeschön

Aber du hast doch mit XE die Möglichkeit der Anonymen Methoden und da gibt es einen sehr charmanten Ansatz von Uwe Raabe

Ich würde aber so gut wie immer statt Synchronize den Queue verwenden (manchmal muss halt Sync sein, aber beim reinen Abliefern von Informationen ...).
Nur ganz zum Schluss mindestens einmal noch Synchronize , damit auch wirklich alles übertragen wird.

Der Vorteil bei Queue ist ja, dass zwar synchronisiert wird, aber ohne den laufenden Prozess zu unterbrechen. Bei Synchronize wartet beide Threads aufeinander, bis diese synchron laufen, verarbeiten die Informationen und dann geht es für beide erst wieder weiter.

Und warum soll de Thread darauf warten, bis da was auch immer auf den Bildschirm geklatscht werden kann.
Das Fenster ist doch schon groß und kann das ganz alleine

Zitat von DeddyH:

Müsste die Deklaration von SyncError dann aber nicht aus dem private-Abschnitt verschwinden?

jooo ... habs berichtigt

[wicht]

Zitat:

Aber du hast doch mit XE die Möglichkeit der Anonymen Methoden und da gibt es einen sehr charmanten Ansatz von Uwe Raabe

Aha, ich war zu voreilig. Habe mir XE gestern bestellt, aber musste mein Profil vorher schon anpassen .. Aber danke für diese Information, werde mich, wenn die Bestellung durch ist, auf jedenfall mal mit den anonymen Methoden auseinandersetzen.

Nochmal Danke und LG

[himitsu]

oder ThreadHelper (mit anonymen Methoden ab D2009), bzw. AsyncCalls

[Sir Rufo]

Verflixte Technik ... geht doch nicht, da "Symbol SyncError kann nicht erfasst werden"

Na dann am besten auf XE umsteigen

Zitat von Sir Rufo:

Tja, das ist mit der Delphi-Version blöde ... bei den neueren Versionen macht man das ganz charmant über Anonyme Methoden.

Aber so sollte es auch charmant gehen:

Delphi-Quellcode:

type
  TInstError = procedure(const Content: String) of object;
 
  TMyOwnThread = class(TThread)
  private
    FInstError: TInstError;
    // procedure SyncError; @DeddyH: logisch muss die hier raus :o)
    CallError( const Content : string );
  public
    property InstError: TInstError read FInstError write FInstError;
  end;
 
implementation

procedure TMyOwnThread.CallError( const Content : string );
procedure SyncError;
begin
  if Assigned( FInstError )
    then FInstError( Content );
end;
begin
  Synchronize( SyncError );
end;
 
procedure TMyOwnThread.Execute;
begin
  ...
  // Error 1
  CallError( 'Fehler 1' );
  ...
  // Error 2
  CallError( 'Fehler 2' );
  ...
  // Error 3
  CallError( 'Fehler 3' );
  
  usw.
end;


procedure Form1.InstError(const Content: String);
begin
  RichEditError.Lines.Add(Content);
end;