VCL Multithread zB. TBitMap Zugriff

[himitsu]

Zitat von bernhard_LA:

ist dies die beste Lösung zu diesem Thema ?

Es kommt drauf an, was genau du machen willst.

Das Create wird noch im Hauptthread verarbeitet, daher kann man dort alles machen, was auch ohne Thread möglich ist.

Wenn die übergebenen Objekte nirgenwo in der VCL benutzt werden, also wenn die VCL, bzw. der Hauptthread oder ein anderer Thread nicht darauf zugreifen, dann kann man danach im Thread diese Objekte problemlos nutzen.

[Namenloser]

Also bei TBitmap bzw. TCanvas im speziellen reicht es nach meiner Erfahrung, (Bitmap.)Canvas.Lock/Unlock aufzurufen.

[himitsu]

Hmm, von der Absicherung her sollte das dann wohl der CriticalSection Sperrung entsprechen.

[bernhard_LA]

könnte ich mir durch diesen Ansatz eine ThreadSafe VCL Zusammenbasteln,
ich müsste halt die wichtigsten Funktionen innerhalb von .Create (....) oder .... bereitstellen; Mir gehts um das Konzept - möglichst flexibel - gut lesbar - einfach - Stabil .....

Delphi-Quellcode:

  THreadSafeMemo = class(TThread);


     Fmemo : Tmemo; 

      constructor Create(amemo : TMemo)

      procedure AddText (aString : String);

      .....
  end;


 ThreadSafeMemo.constructor Create(amemo : TMemo)
 begin
       Fmemo := Tmemo;
.....
end;

[Bernhard Geyer]

Zitat von himitsu:

Das Create wird noch im Hauptthread verarbeitet, daher kann man dort alles machen, was auch ohne Thread möglich ist.

Wenn die übergebenen Objekte nirgenwo in der VCL benutzt werden, also wenn die VCL, bzw. der Hauptthread oder ein anderer Thread nicht darauf zugreifen, dann kann man danach im Thread diese Objekte problemlos nutzen.

Nicht unbedingt. Das Hauptproblem von VCL-GUI-Controls ist ja das die Win32-Ressourcen Thead-Affine sind. D.h. ein (Fenster-)Handle darf nur im Thread verwendet werden indem er erzeugt wurde. D.h. will man ein (T)Bitmap im Thread verändern so muss es auch in diesem erzeugt werden.

[Namenloser]

Hmm, aber es ist doch möglich, selbst Fenster von fremden Anwendungen zu manipulieren (z.B. einen disableten Button zu enablen, SetWindowPos etc.)
Was Bitmaps angeht: Da habe ich gerade erst ein kleines Programm geschrieben, bei dem ein Thread auf ein Bitmap zeichnet, das im Constructor des Threads erzeugt wird (also somit noch im Hauptthread), und dieses regelmäßig auf das Canvas einer Form kopiert. Läuft absolut zuverlässig und stabil, solange für beide Canvasse jeweils Lock und Unlock aufgerufen wird.

Ich dachte das Problem bei der VCL wären eher globale Variablen, die intern zur Verwaltung dienen.

[Blup]

Zitat von NamenLozer:

Hmm, aber es ist doch möglich, selbst Fenster von fremden Anwendungen zu manipulieren (z.B. einen disableten Button zu enablen, SetWindowPos etc.)

Das macht man dann aber über Windowsnachrichten, die dann von dem für das Fenster zuständigen Thread abgearbeitet werden.

Zitat von NamenLozer:

Ich dachte das Problem bei der VCL wären eher globale Variablen, die intern zur Verwaltung dienen.

Wenn das so einfach währe, hätte Borland damals sicher auch eine threadsichere VCL gebaut.

Dein Beispiel mit dem Memo kann so nur stabil funktionieren, wenn der Thread alle Zugriffe und Aktionen mit dem Memo im Synchronize ausführt.

[Uwe Raabe]

Zitat von Blup:

Dein Beispiel mit dem Memo kann so nur stabil funktionieren, wenn der Thread alle Zugriffe und Aktionen mit dem Memo im Synchronize ausführt.

Das Problem ist eben, daß man zwar seine eigenen Zugriffe auf VCL-Komponenten und ihre Eigenschaften threadsicher gestalten kann, aber nicht die der VCL selbst.

[himitsu]

Jupp, wärend man dem grade im Thread was mit dem Memo macht, könnte es auch passieren daß die VCL zur selben Zeit auch was damit anstellt und sei es nur ein Repaint.

[Bummi]

Wenn eine GUI Kommunikation synchronized erfolgen kann, dei Hauptarbeit aber in einem Thread erfolgen kann könnte mein Anhang hier gegf. interessant sein http://www.delphipraxis.net/130951-b...d-laden-2.html