AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

VCL not thread save

Ein Thema von stahli · begonnen am 6. Mär 2014 · letzter Beitrag vom 8. Mär 2014
Antwort Antwort
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.352 Beiträge
 
Delphi 11 Alexandria
 
#1

AW: VCL not thread save

  Alt 6. Mär 2014, 16:26
@Sir

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

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...


@sx2008

Ich versuche das aus dem von Dir genannten Grund gerade mal ohne VCL.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von sx2008
sx2008

Registriert seit: 15. Feb 2008
Ort: Baden-Württemberg
2.332 Beiträge
 
Delphi 2007 Professional
 
#2

AW: VCL not thread save

  Alt 6. Mär 2014, 16:51
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.
fork me on Github
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#3

AW: VCL not thread save

  Alt 6. Mär 2014, 17:39
@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.
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).
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von Union
Union

Registriert seit: 18. Mär 2004
Ort: Luxembourg
3.492 Beiträge
 
Delphi 7 Enterprise
 
#4

AW: VCL not thread save

  Alt 6. Mär 2014, 18:20
@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.
Ibi fas ubi proxima merces
sudo /Developer/Library/uninstall-devtools --mode=all
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.352 Beiträge
 
Delphi 11 Alexandria
 
#5

AW: VCL not thread save

  Alt 6. Mär 2014, 19:00
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.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#6

AW: VCL not thread save

  Alt 6. Mär 2014, 19:14
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.
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.352 Beiträge
 
Delphi 11 Alexandria
 
#7

AW: VCL not thread save

  Alt 6. Mär 2014, 19:19
Wie schon mal gesagt: Schade, dass da jeder sein eigenes Süppchen gekocht hat.
Meins köchelt jetzt eben auch noch...
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
HeZa

Registriert seit: 4. Nov 2004
Ort: Dortmund
182 Beiträge
 
Delphi 10 Seattle Professional
 
#8

AW: VCL not thread save

  Alt 7. Mär 2014, 11:01
Hallo Stahli,

Wie schon mal gesagt: Schade, dass da jeder sein eigenes Süppchen gekocht hat.
Meins köchelt jetzt eben auch noch...
Ich habe schon zuviel schlechten Threading-Code gesehen. Entweder wurden die Risiken der Threading Programmierung nicht vollständig berücksichtigt, was dann dazu führte, dass das Programm unvorhersehbar und unerklärlich merkwürdiges Verhalten zeigte oder aber es waren soviele Critical-Sections darin, dass man sich fragte warum überhaupt Threads verwendet werden.

Deswegen habe ich mir geschworen, dass ich vor dem nächten Projekt mit Threading, zu allererst die Fähigkeiten der OmniThreadLibrary auschecken werde.

Da hat ein echter Threading-Experte seit 2008 seine Wunsch-Library gebaut und (und das ist viel zu selten der Fall) sie auch dokumentiert. In dem Blog des Autors kannst du viel über die Entstehung der OmniThreadLibrary erfahren, aber auch über Threading allgemein.

Bevor als die eigene Suppe überbrodelt, würde ich mal die OmniThreadLibrary schmecken.

Ciao Heinz Z.
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:53 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz