Code vom Thread in einen Timer umziehen?

[DeddyH]

Anscheinend bin ich doch nicht der Einzige, der dieses Timer-Geraffel nicht versteht, das beruhigt mich *puh*.

[Bambini]

Zitat:

Zitat von Luckie (Beitrag 1351981)

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.

[Jim Carrey]

Zitat:

Zitat von Luckie (Beitrag 1351984)

Ein Timer ist kein Thread! Ein Timer wird durch Windows Nachrichten ausgelöst (WM_TIMER).

Das ist mir vollkommen klar. Wenn du den Verlauf des Themas gelesen hättest wüstest du auch warum ich Timer und Threads in einen Topf werfe.

Zitat:

Zitat von stahli (Beitrag 1351985)

...

Vielen Dank für die ausführliche Antwort.

[DeddyH]

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

[Jim Carrey]

Zitat:

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.

Genau. Und das macht mein zweiter Thread nebenher immer, wenn die ausgerechneten Prozent der verarbeitung höher sind als die davor UND wenn eine gewisse Zeitspanne zutrifft.

[Bambini]

Zitat:

Zitat von DeddyH (Beitrag 1351989)

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

Nun, je nachdem, was da gerade für ein Paket in Arbeit ist (z.B. ein Download eine Delphi.ISO),
kann es bei einem riesigen Paket recht lange dauern, bis da 1% fertig sind und einer klingelt. Bis dahin sieht und hört man nix.

[DeddyH]

Und was genau würde ein Timer daran ändern?

[Bambini]

Zitat:

Zitat von DeddyH (Beitrag 1351993)

Und was genau würde ein Timer daran ändern?

Der sagt dir dann eben, dass da gerade erst mal 0,00001% erledigt sind.

[stahli]

Aber damit schießt Du mit Kanonen auf Spatzen. ;-)

Irgendwann kommst Du dazu, dass die Organisation der simplen Zwischennachricht aufwendiger wird als Deine Berechnung selbst.

Du kannst das natürlich so machen, aber es ist m.E. unnötig kompliziert und bietet keinen wirklichen Vorteil.

Hast Du denn irgendwie Hänger oder spürbare Verzögerungen, wenn Du aus dem Arbeitsthread einfach synchronisiert MyForm.ShowProgressValue(Value) aufrufst (ohne zweiten Thread und ohne Timer)?

Wenn ja, müsste man nach der Ursache schauen, aber dann stimmt irgendwo anders sicher etwas nicht.

Wie lange arbeitet der ArbeitsThread eigentlich und wie viele Zwischenschritte werden erledigt (also wie viele Progress-Aktualisierungen gibt es)?

[Jim Carrey]

Zitat:

Hast Du denn irgendwie Hänger oder spürbare Verzögerungen, wenn Du aus dem Arbeitsthread einfach synchronisiert MyForm.ShowProgressValue(Value) aufrufst (ohne zweiten Thread und ohne Timer)?

Falls du damit mich meinst: gefühlt war der Prozess langsamer, als es noch 1 Thread war.
Ich habe natürlich immer total übertrieben und direkt eine for-schleife 10.000 Mal dieselbe Arbeit machen lassen. Aber bei meiner Software ist Zahl 10.000 gar nichts.

Ich sehe das halt so... warum muss man dem Benutzer nach jedem Objekt der for-Schleife eine Änderung an der GUI mitteilen, wenn das auch alle 1000ms geht.
Und diese 1000ms kann ich in einem zweiten Thread wesentlich sauberer und besser berechnen als im Arbeiterthread.