Die Anzeige informieren, dass sich etwas verändert hat und die Anzeige holt dann (sobald es möglich ist) die neuen Werte und stellt diese dar.

Der UI-Thread sollte eigentlich fast immer schlafen (idle) und nur kurz aufleben um neue Informationen anzuzeigen oder Eingaben vom User entgegennehmen und diese dann weiterreichen.

Idealerweise müsste der Business-Layer (allgemeiner: alles was nicht zu UI gehört) im eigenen Thread-Kontext laufen, was aber in den meisten Fällen nicht passiert, da sich die Laufzeit der Aktionen meistens auf ein paar Millisekunden beschränkt (wenn überhaupt messbar) und ein eigener Thread-Kontext wäre dort mit Kanonen auf Spatzen schießen.

Somit werden sich nur die langwierigen Abläufe herausgepickt und diese werden in einen separaten Thread-Kontext verschoben.

Zurück zu deinem Beispiel mit der Schleife:
Die Schleife gehört in einen eigenen Thread und die Werte in ein Daten-Objekt. Das UI wird informiert, dass sich die Daten geändert haben und dann entscheidet das UI wann genau es diese neuen Informationen abruft und darstellt (ASAP oder maximal alle x Millisekunden).

Die meisten Programmier-Anfänger haben allerdings vor dem Start ihrer Karriere auch das Prinzip des UI nicht verstanden bzw. sich darüber keinen Kopf gemacht (ich möchte mich dort unbedingt eingeschlossen wissen). Daher auch diese "Fehler", denn es passiert etwas anderes als man erwartet hat. Es passiert aber nun mal genau das, was man programmiert hat. Diese Erwartungshaltung rührt aber von Unwissenheit her, und das schützt nun mal nicht vor der Strafe

Die Synchronize - Methode von TThread kann man in neuen Delphi Versionen auch mit einer Closure aufrufen.
Dazu ein interessanter Artikel von Uwe Rabe:
http://www.uweraabe.de/Blog/2011/01/...th-parameters/
Ich denke das ist der Weg den man gehen muss da man die VCL selbst nicht ändern kann.

Zitat von sx2008:

Die Synchronize - Methode von TThread kann man in neuen Delphi Versionen auch mit einer Closure aufrufen.
Dazu ein interessanter Artikel von Uwe Rabe:
http://www.uweraabe.de/Blog/2011/01/...th-parameters/

Wobei das hier Einige () auch schon vor 2011 gemacht haben.

Denn das ist eigentlich sogar eine der wenigen "einfachen" Möglichkeiten Parameter "threadsicher" an den Zielthrad zu übergeben.
(ohne sich eine threadsichere globale Variable anzulegen, oder gar gleich eine ganze Liste, wenn diese Methode aus mehreren Threads gleichzeitig aufgerufen werden könnte)

markieren

Delphi-Quellcode:

// innerhalb von TThread.Execute
Synchronize(procedure
  begin
    CallMyProgress(PercentComplete);
  end);

markieren

Delphi-Quellcode:

// in Threads, die nicht von TThread abstammen oder wo man auf die TThread-Instanz keinen Zugriff hatte.
TThread.Synchronize(nil, procedure
  begin
    CallMyProgress(PercentComplete);
  end);

Wobei man ja mindestens seit XE3 sich eine Pseudoinstanz des eigentlichen TThreads oder gar eine Instanz für etwas, daß dein TThread ist, erstellen lassen kann.
Ich glaub das ging mit TThread.CurrentThread, oder so.

Aber vor dem TThread.Synchronize oder TThread.Queue immer vorher prüfen ob man sich ausserhalb des MainThread-Kontext aufhält.

markieren

Delphi-Quellcode:

if MainThreadID <> TThread.CurrentThread.ThreadID then
  TThread.Synchronize(...)
else
  ...
end;

Die Funktionen prüfen das eigentlich selber ab,
ABER für das Debuggen macht sich diese Prüfung besser.

Jedenfalls so weit ich das mitbekommen hab, in leidlichen Debugsessions.
Denn wenn es innerhalb des synchronisieren Codes eine Exception gibt, dann langes man gerne sonstwo in der CPU-Ansicht und noch schlimmer wird es, wenn man EurekaLog im Code hat (das muß dabei noch nichtmal aktiv sein).



Außer daß TThread.Queue im MainThread nicht unbedingt das macht, was ich ihm unterstellt hatte ... gibt es sonst keine Probleme (wenn es nicht kallt).

Zitat von Sir Rufo:

Aber vor dem TThread.Synchronize oder TThread.Queue immer vorher prüfen ob man sich ausserhalb des MainThread-Kontext aufhält.

markieren

Delphi-Quellcode:

if MainThreadID <> TThread.CurrentThread.ThreadID then
  TThread.Synchronize(...)
else
  ...
end;

... und bevor man das macht, immer zuerst prüfen ob man sich in Delphi 2009 aufhält

Delphi TThread.CurrentThread and EAccessViolation

Bis 2009 war System.IsConsole geeignet und wird z.B. im Indy Telnet Client Quelltext (IdTelnet) verwendet, aber ab 2010 ist CurrentThread natürlich erste Wahl.

Zitat von Sir Rufo:

Aber vor dem TThread.Synchronize oder TThread.Queue immer vorher prüfen ob man sich ausserhalb des MainThread-Kontext aufhält.

markieren

Delphi-Quellcode:

if MainThreadID <> TThread.CurrentThread.ThreadID then
  TThread.Synchronize(...)
else
  ...
end;

Warum? Geht da was kaputt wenn man in den eigenen Thread synchronisiert?

Zitat von taveuni:

Zitat von Sir Rufo:

Aber vor dem TThread.Synchronize oder TThread.Queue immer vorher prüfen ob man sich ausserhalb des MainThread-Kontext aufhält.

markieren

Delphi-Quellcode:

if MainThreadID <> TThread.CurrentThread.ThreadID then
  TThread.Synchronize(...)
else
  ...
end;

Warum? Geht da was kaputt wenn man in den eigenen Thread synchronisiert?

TThread.Synchronize

Zitat:

Warnung: Rufen Sie Synchronize nicht aus dem Haupt-Thread auf. Dies kann zu einer Endlosschleife führen.

Vermutlich ein Bug, bezüglich auf sich selber warten und so.

Zitat von himitsu:

Vermutlich ein Bug

Nicht alles, was nicht so funktioniert wie du willst, ist gleich ein Bug
Insbesondere dann nicht, wenn das Verhalten dokumentiert/by-design ist. Wenn dir die API nicht gefällt, ist das eine andere Sache.