Zitat:

Und genau das ist der Punkt den ich meine. Siehst du wie aufwändig und fummelig das jetzt schon wird?

Wieso aufwendig? In meinem Fall sind das circa 40 Zeilen Code die dafür sorgen, dass die GUI an den richtigen Stellen aktualisiert wird. Das ist doch nicht aufwendig
Der Thread hat mehrere Kriterien:

- while not Terminated
-- schlafe 25ms
-- berechne neue ProgressBar-Position
-- ist die Position größer als die alte UND ist mindestens Zeit X vergangen
--- JA > GUI aktualisieren

Worauf ich hinaus wollte war nur:

Dein Thread wird ja wohl "echte" Arbeit tun und nicht einen Progressbar-Indicator hochsetzen. Der Thread sollte sich um ebendiese Arbeit kümmern. Immer wenn du an der Oberfläche was änderst musst du evtl. auch diesen Thread anpassen. In zwei Jahren besteht mindestens die Hälfte deines Threads aus Code für irgendwelche Feinheiten der Oberfläche während der Code für die eigentliche Arbeit immer weiter dahinter versumpft.

Genau, deswegen hab ich ja zwei Threads.
Ich wollte "Arbeit" von "GUI-Anpassung" trennen.

Vorher war es ungefähr so...

- Mach deine Arbeit Schritt 1
-- prüfe A
-- prüfe B
-- prüfe C
-- passe die GUI an
- Mach deine Arbeit Schritt 2
...
..

Und damit der Arbeiterthread nun seine Arbeit in Ruhe machen kann, hatte ich das vor ein paar Monaten getrennt.

Zitat:

In zwei Jahren besteht mindestens die Hälfte deines Threads aus Code für irgendwelche Feinheiten der Oberfläche während der Code für die eigentliche Arbeit immer weiter dahinter versumpft.

Ich verstehe solche Aussagen nie.
Warum sollte der Thread versumpfen? Wenn ich etwas an meinem Programm rändere, ändere ich auch überall das, was damit zusammenhängt. Da kann nix versumpfen

Ein Thread zwischen Arbeitsthread und Gui würde Sinn machen, wenn der Arbeitsthread irgendwelche Ergebnisse in einer Liste bereitstellt, die die Gui (oder ein anderer Thread) nach und nach abarbeiten muss.

Das ist ja aber vorliegend offenbar nicht notwendig.

Also würde ich nach den Zuständigkeiten schauen.

Der Arbeitsthread berechnet etwas und kann einen Fortschrittswert bereit stellen.

Die GUI dient der Darstellung und Bedienung durch den User.

Da der Thread ohnehin läuft und die Darstellung über Synchronize problemlos möglich ist, würde ich das dort veranlassen.

Im Formular kann der User sich - wenn er will - normal bewegen und etwas schreiben und so nebenbei ändert sich die Progressbar Stück für Stück.

Die GUI selbst muss nicht wissen, was der Thread tut oder wie weit er ist. Ein kleiner Teil der GUI-Funktionalität wird einfach vorübergehend vom Thread gesteuert.

Da braucht es m.E. keinen zweiten Thread und keinen Timer.



Anders wäre es (nur), wenn die Prozesse vollständig getrennt wären, also z.B. auf verschiedenen Rechnern im Netzwerk oder so.
Dann könnten der Arbeitsshread im Server und die GUI im Client natürlich nicht aufeinander zugreifen. Dann wäre im Client ein Timer oder Thread erforderlich, der die neuen Daten abfordert und zeichnet.
Das ist ja aber hier nicht gegeben.

Erkläre doch mal, warum Du nicht MyForm.ShowProgressValue(Value) synchronisiert aufrufen willst. Das ist doch die einfachste und sauberste Lösung (wobei es mit einem Event noch sauberer, aber etwas aufwendiger wäre).

Also den Sinn eines zweiten Threads, um die GUI zu aktualisieren erschließt sich mir nicht so ganz. Und mit einem Timer zu guckcjen wie weit der Thread ist, ist auch etwas sinnbefreit.

Der Thread weiß doch am besten wie weit er ist. Also kann er auch der GUI seinen Fortschritt mitteilen (Synchronize, Events, Nachrichten). Wenn ich ein Paket erwarte gehe ich doch auchnicht alle fünf Minuten vor die Tür und gucke, ob der Paketbote vor der Tür steht. Dazu habe ich eine Türklingel (Event, Nachricht), die mir sagt, dass der Paketbote vor der Tür steht.

Hier gibt es nich ein etwas älteres Tutorial zu Threads von mir: http://michael-puff.de/Programmierung/Delphi/Tutorials/

Ist ein Timer nicht auch eigentlich ein Thread? Somit wäre es gleichwertig, ob ich per 2. Thread oder Timer den Fortschritt des 1. Thread "überwache".

Da ein Thread ja eher Teil der Business-Logik ist, ist es mMn gar nicht so verkehrt, dass der Arbeiter-Thread nicht selbstständig die GUI ändern kann. Auch sollte ein Thread nicht unbedingt selbst entscheiden können müssen, wann die GUI aktualisiert werden muss.

Insofern find ich eine Kombination aus der von ConnorMcLeod vorgeschlagenen Event-Property, plus einer Info wann diese feuern soll (z.B. alle 10% Fortschritt) die man dem Thread von Aussen mitgibt in diesem Fall sinnvoll. Dazu dann ruhig auch eine von Aussen abfragbare Property, die den aktuellen Fortschritt o.ä. ausgibt und schon ist man flexibel, wie man den Thread nutzen möchte.

Für mich stand damals im Vordergrund den Arbeiterthread zu entlasten.
Ich wollte Arbeit und Anzeige trennen was bis heute gut klappt.

Aber da ich irgendwo in diesem Forum mal gelesen habe, dass man dafür eigentlich einen Timer nimmt, dachte ich frage ich mal nach. Aber da gehen die Meinungen ja stark auseinander.

Zitat von Luckie:

Wenn ich ein Paket erwarte gehe ich doch auchnicht alle fünf Minuten vor die Tür und gucke, ob der Paketbote vor der Tür steht. Dazu habe ich eine Türklingel (Event, Nachricht), die mir sagt, dass der Paketbote vor der Tür steht.

Aber es kann den den Hauptthread extrem nerven, wenn der Postbote jede Millisekunde an der Tür schellt, nur weil er gerade wieder ein 0,000001% Päckchen hat. Das mag ja ganz ganz nett sein, aber dann ist der Hauptthread doch wieder nur mit dem Postbosten beschäftigt. Daher hat die Lösung: Selbst und in regelmäßigen Zeiten an die Tür zu gehen und dann auf ein mal alle Päckchen rein zu holen, nicht schlecht.

Dann sagt man dem Boten eben, dass er nur bei jedem vollen Prozent klingeln soll. Das ist doch keine Raketentechnik.