Hallo zusammen,

die meisten Programme, die ich schreibe, beschäftigen sich damit, Dateien zu lesen, die Daten zu verarbeiten und wieder neue Dateien zu schreiben. Da diese Dateien oft etwas größer als 100 MB sind, dauert die Verarbeitung auch etwas. Dann ist es kein Fehler den Benutzer über einen Satzzähler oder einen Fortschritsbalken oä zu informieren.
Da ich versuche die Verarbeitungsschritte von der Oberfläche zu trennen habe ich das Problem den Zähler an die Oberfläche zu übergeben.
Bisher habe ich zwei Wege beschritten:

a) Mit Hilfe des Timers lese ich eine Zählervariable in der Verarbeitungsunit aus,
b) Ich übergebe ein Label/Fortschrittbalken an die Verarbeitungsroutine. Ist der Wert des Labels <> nil dann wird der Zähler ausgegeben.

Beide Wege funktionieren.

Nun hätte ich gerne einen Tip wie ich ohne großen Overhead Oberfläche und Verarbeitung stärker entkoppeln kann. Wichtig ist daß die meiste Rechenzeit wirklich für die Verarbeitung und nicht für die Oberfläche genutzt wird.

Vielen Dank im voraus
K-H

ich würde die Verarbeitung in einen Thread auslagern und von diesem per PostMessage ab und zu eine Statusmeldung an den Hauptthread schicken.

Hall,

was ist denn an b) so verkehrt?
Ähnlich mache ich es auch.


Heiko

@Sir Thornberry
Da schreckt mich etwas der Aufwand (naja ich bin ein Datenschafler und von Threads habe ich keine praktische Ahnung)

@hoika
zum einen schleppe ich mir über das uses vollkommen überflüssige units in die verarbeitung ein, zum anderen steuere ich innerhalb der Verarbeitung noch die Oberfläche. Das ist sicher besser als "Man sieht, das man nichts sieht, also arbeitet er" aber die reine Lehre ist das nicht. Was meinst Du was ich geflucht habe als ich TP-Programme nach Delphi portiert habe. Da ist die Methode a) schon etwas wartungsfreundlicher weil das meiste innerhalb der Unit abläuft. Nur Fragst Du dich manchmal "wofür brauch ich eigentlich 'Zähler'".

erst einmal vielen Dank für Eure Reaktion
K-H

Moin, moin,

Oft habe ich zur Datenausgabe eine Variable vom Typ TStringList definiert. Die wird im Programm zunächst der Lines Eigenschaft eines TMemos oder TRichEdits zugewiesen. In den Routinen schreibe ich dann Hinweise in meine LokalStringList die in meinen Routinen fest verankert ist. Dadurch brauche ich kein visuelles Objekt in den Rechenroutinen und habe zudem eine mehrzeiliga Ausgabe.

Grüße // Martin

Zitat von p80286:

b) Ich übergebe ein Label/Fortschrittbalken an die Verarbeitungsroutine. Ist der Wert des Labels <> nil dann wird der Zähler ausgegeben.

Nimm lieber einen Event a la OnStep. Der kann dann nil sein, Label1.Caption setzen, ein Writeln machen oder sonstwas tun - schön entkoppelt.

HTH,
Uli.

Die Verarbeitung in einen Thread auslagern, der Threadklasse das GUI Fensterhandle überreichen und dann mit Messages arbeiten dürfte der generischste und entkoppelteste Weg sein, den du erreichen kannst. Dabei steht dir dann u.a. auch frei, ob und welche Messages du überhaupt nachher anzeigen lassen willst, und in welcher Form (Text, Gauge, Balken etc.).

Noch weiter gedacht, könnte man sich vorstellen, dass man mehrere Fenster(handles) in der Threadklasse hinterlegt, so dass evtl. sogar jeder Signaltyp (wenn man mal mehr als nur einen Counter hat) theoretisch an ein anderes Fenster gesendet werden kann. Damit könnte man dann sogar realisieren, dass eine von TEdit abgeleitete Klasse selbst auf eine Message aus dem Thread reagiert und die Anzeige übernimmt, ohne dass in einem zentralen Formular eine Verteilungslogik her müsste. Einfach direkt an diese Klasse senden lassen.

Ich denke schon, dass es sich langfristig sehr lohnen würde, sich mit Threads zu beschäftigen. Viele machen sich bei dem Thema auch oft zu viel in die Hose; es ist wirklich nicht kompliziert, wird aber wie so oft heuertage durch eine ganz tolle hochtrabende Begriffswelt verklausuliert, die erstmal nur erdrückend aussieht. Die Konzepte hinter Synchronizing, Locking, Priority, WaitForSingleObject und so weiter sind an sich recht trivial - zumindest wenn man nicht grad letzte Woche seinen ersten Compiler gekauft hat

Hallo zusammen,

danke für Eure Tips, da ist das Wochenende ja gerettet.

Ich werde das alles mal ausprobieren, vielleicht sind Threads ja wirklich DIE Lösung!

viele Grüße und ein schönes Wochenende
K-H

Zitat von Medium:

Die Verarbeitung in einen Thread auslagern, der Threadklasse das GUI Fensterhandle überreichen und dann mit Messages arbeiten dürfte

Ob das nicht auch kracht, da die problematische VCL und Threadproblematik an der Win32-GUI liegt da Fensterhandle eine Thread-Affinität besitzen: Sie dürfen nur im erzeugenden Thread angesprochen werden.

Und wenn die den Overhead eines Thread vermeiden willst, ruf in der Schleife regelmäßig, aber nicht zu oft, Application.ProcessMessages auf. Dieser Aufruf veranlasst das Fenster seine Nachrichtenschleife abzuarbeiten. dies hat eben auch zur Folge, dass dein Label aktualisiert wird.