Wie gesagt wenn ich diese Art von locken verwende (MyBild.Canvas.lock) kommt es zu Fehlermeldungen.
Lasse ich es weg funktioniert es in der Regel.
Mein Problem ist jedoch, dass es bei meinem Beispielprojekt funktioniert, nicht aber bei meinem größeren Projekt.
Ich versuce gerade herauszufinden, wo der Unterschied liegt.

Na toll,

habe gerad herausgefunden, dass die Zeichenprozedur des Threads aufhört richtig zu arbeiten, kurz nachdem man mit der Maus über das TImage der Form fährt ._.

Hier ist die Beispielunit, ihr könnt da ja mal testen ob es bei euch auch aufhört zu arbeiten.

Edit: Ausversehen falsche Datei hochgeladen, stimmt jetzt aber...

...wie gesagt wenn du korrekt lockst/unlockst geht das (zumindestens bei mir unter xe5) problemlos...

zusammenfalten · markieren

Delphi-Quellcode:

procedure TPaintThread.Execute;
begin
 While (Terminated = False) do
 begin
   MyBild.Canvas.lock;
   Original.Canvas.Lock;
   try
     MyBild.Width := random(500) + 500;
     MyBild.Height := random(500) + 500;
     MyBild.Canvas.Draw(random(25) + 1, random(25) + 1, Original);
     MyBild.Canvas.Rectangle(random(25) + 1, random(25) + 1, random(50) + 25, random(50) + 25);
   finally
     MyBild.Canvas.unlock;
     Original.Canvas.Unlock;
   end;
   Synchronize(Zeichnen);
 end;
end;

Ups, habe vergessen die 2te Bitmap (original) mit zu locken/unlocken...
Das hat scheinbar einen großen Effekt gehabt.

Zitat von Whookie:

...wie gesagt wenn du korrekt lockst/unlockst geht das (zumindestens bei mir unter xe5) problemlos...

zusammenfalten · markieren

Delphi-Quellcode:

procedure TPaintThread.Execute;
begin
 While (Terminated = False) do
 begin
   MyBild.Canvas.lock;
   Original.Canvas.Lock;
   try
     MyBild.Width := random(500) + 500;
     MyBild.Height := random(500) + 500;
     MyBild.Canvas.Draw(random(25) + 1, random(25) + 1, Original);
     MyBild.Canvas.Rectangle(random(25) + 1, random(25) + 1, random(50) + 25, random(50) + 25);
   finally
     MyBild.Canvas.unlock;
     Original.Canvas.Unlock;
   end;
   Synchronize(Zeichnen);
 end;
end;

Ich musste leider feststellen, dass, wenn man diesen Code eine Weile durchsteppen lässt, es zu einer EAccessviolation kommt.
Diese findet allerdings nicht im Threadablauf, sondern im Prozess der Hauptform statt, während das Bild per Synchronize gezeichnet wird.
Diese EAccessViolation findet sogar dann statt, wenn man den Code so abändert:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TPaintThread.Execute;
begin

 While (Terminated = False) do
 begin

  try

  Synchronize(Zeichnen);

  finally

  end;


 sleep(1);
 
 end;
end;



procedure TPaintThread.Zeichnen;
begin
//
end;

Das bedeutet, dass allein das Aufrufen der (leeren) Synchronize-Methode einen EAccess-Error hervorruft, zumal nichts anderes der Auslöser sein kann.
Versteht ihr, was da schief läuft?
(Der Fehler kommt oft nach einigen Sekunden, manchmal aber auch garnicht)

Ich habe das jetzt nochmal erweitert getestet und festgestellt, dass es nicht an der Snchronize-Methode liegt.
JEDE Kommunikation von MainForm zu Thread per Prozedur kann (nach 10-100 Aufrufen im Mittel) diese Access-Violation beim Durchsteppen auslösen.
Was ich mich jetzt frage ist:
-Wieso kommt es dazu?
-Lässt es sich vermeiden? (Vermutlich nicht)
-Hat die Fehlermeldung beim Durchsteppen auch Relevanz beim normalen Ablauf des Programms?

Also wir müssen uns hier auf eine korrekte Sprache einigen, denn sonst weiß keiner was wirklich gemeint ist. Beim Thema Multithreading ist das einfach unerlässlich.

Es kommt immer auf den Thread-Kontext an.

Wenn du also bei irgendetwas im Bereich Multithreading Probleme hast, dann ist es sehr wichtig, dass du dabei den Thread-Kontext mit angibst, und nicht welche Form da was aufruft.

Auch die Methode einer Form kann in jedem beliebigen Thread-Kontext aufgerufen werden, niemand hindert dich daran. Greifst du in irgendeinem Thread-Kontext <> MainThread-Kontext auf die VCL zu, dann kann es rummsen - das ist ja das Gemeine, es rummst nicht immer

Den aktuellen Thread-Kontext fragt man ganz einfach mit TThread.CurrentThread.ThreadID ab (bei Delphi 7 war das GetCurrentThreadID oder so) und den MainThread-Kontext mit MainThreadID . Sind die beiden Werte unterschiedlich, dann ist man eben nicht im MainThread-Kontext.

Die Art zu Locken verriegelt auch über eine globale CriticalSection (das gewählte Canvas ist hier eh "wurscht"), was heißt daß sich Deine Threads gegenseitig blockieren.
Wenn Du eine Möglichkeit sucht ohne Canvas in mehreren Threads parallel zu arbeiten um am Schluss das ganze synchronisiert auf die Oberfläche zu bringen könntest Du Dich mit GDI+ beschäftigen. Hier funktioniert es auch ohne Canvas/HDC mit GdipGetImageGraphicsContext/GdipCreateBitmapFromScan0.
Da Bilsen erst ab D2009 funktioniert und progdigy nicht mehr existiert könntest Du das benötigte bei http://lummie.co.uk/gdi-controls-for-delphi/ finden.

Zu Bummis Vorschlag: Viel zu kompliziert. Das geht wunderbar mit Delphis ganz normalem TBitmap. Man sollte eben wie schon zuvor erwähnt, in Threads immer nur mit Kopien arbeiten, oder zumindest ein wasserdichtes Synchronisationskonzept haben. Ich habe schon zig Programme geschrieben, die auf diese Weise aufwändige Bilder parallel zeichnen. Dem TE jetzt zusätzlich zum Thema Threads auch noch mit GDI+ zu kommen, halte ich für viel zu viel auf ein Mal. (Zumal GDI+ praktisch schon totgesagt ist, und somit nicht mal viel für die Zukunft gelernt ist.)