Zitat von stahli:

Ich versuche das aus dem von Dir genannten Grund gerade mal ohne VCL.

Das würde ich nur für ganz kleine Anwendungen tun, denn Oberflächen lassen sich mit VCL ca. 10 Mal schneller entwickeln als mit einer Non-VCL Lösung.
Der Ansatz von Uwe Rabe benötigt zwar einige Zeilen Boilerplate-Code dafür kann man aber einer Thread-Klasse relativ bequem Events mit beliebig vielen Parametern verpassen.
Mit den Events wird der Thread und GUI voreinander entkoppelt.
Das ist besser als aus dem Thread direkt die Controls zu manipulieren.
Ausserdem kann man so die gleiche Thread-Klasse in verschiedene Formulare oder Anwendungen einbauen, da die Thread-Klasse kein Wissen über die GUI benötigt.

Zitat von stahli:

@Sir

Früher hat man Automobile mit einer Kurbel in Gang gebracht ... bis es andere Lösungen gab.

Ähm ja ... was hat das jetzt hiermit zu tun?

Menschen sind Sauerstoff-Atmer und du möchtest jetzt Stickstoff-Atmer werden?

Das gesamte Konzept von Windows baut auf diesem UI-In-Single-Thread auf.
Bis vor Windows 7 konnten die einzelnen Anwendungen sogar immer nur brav nacheinander die Forms zeichnen.
Da wurde also jede Anwendung beim Zeichnen mit dem Haupt-Desktop-Maler-Thread synchronisiert.

Zitat von stahli:

Mir wäre eine Lösung, die das Binding und Handling zwischen GUI(s) und BL automatisiert auf jeden Fall sehr willkommen.
Dann kann man sich mehr um das Wesentliche kümmern, hat deutlich weniger Arbeit und dennoch eine flüssige grafische Schnittstelle, die sich für den User gut anfühlt (also gut funktional ist).

Mein Wusch war so etwas schon lange und so langsam etwickelt sich das auch...

Das verbietet dir ja keiner, es gibt aber gewisse Spielregeln beim UI an die man sich halten muss oder die Hütte fliegt einem um die Ohren. Da kann man sich ruhig auf den Boden werfen und die Luft anhalten bis man blau wird. Das Betriebssystem wird lediglich zur Kenntnis nehmen, dass von den Eingabe-Devices kein Input mehr kommt und irgendwann sich schlafen legen (den passenden Energie-Sparmodus vorausgesetzt).

@Stahli: Stell Dir das ganze doch wie eine c/s Architektur (z.B. mit REST/JSON) vor, in der ein Client bis auf die Adresse vom Server keinerlei Daten besitzt. Du hast nur saubere Schnittstellen an die Du Daten von der UI sendest und auch wieder empfängst und darstellst. Dabei sollte es egal sein, ob der Server als Thread der Clientanwendung oder sonstwo läuft.

Zitat von Sir Rufo:

Da kann man sich ruhig auf den Boden werfen und die Luft anhalten bis man blau wird.

Im Supermarkt bekomme ich dann meist einen Lolly, aber nicht immer.
(Rest per Mail)


@Union
Genau so ist mein aktueller Ansatz.

Wir setzen gerade ein MVVM-Konzept ein und eigentlich ist das sehr einfach. Ein bischen mehr Aufwand und einiges an (Binding-)Vorarbeit, aber dann geht das echt einfach. Das einzige, was man auch hier beachten muss, sind die Property-Change-Notifications, die nicht als einfaches Event umgesetzt werden, weil ja die Notification aus einem anderen Thread erfolgt.

Blöd an dem Original-MVVM ist, das man das NotifyPropertyChanged mit dem Namen der Property aufruft, die sich verändert hat. Als String Wir haben das mit Expressions gelöst, die es in Delphi leider nicht gibt, aber -na ja- meckern kann man immer.

Wie schon mal gesagt: Schade, dass da jeder sein eigenes Süppchen gekocht hat.
Meins köchelt jetzt eben auch noch...

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.