-
Forum: Programmieren allgemein
by TheGroudonx,
3. Sep 2014
Das Programm läuft mittlerweile ganz gut, im Vergleich zu vorher hat es nun 0,1 MB/s Datenträgerauslastung.
Seltsam ist, dass nach ca. 30 sek Laufzeit die Datenträgerauslastung vom System von 5% auf 100% hochfährt und dort bleibt, bis das Programm beendet wird.
Wahrscheinlich wieder ein Thread Fehler, nicht wahr? :roll:
Edit: Entwarnung, zwar passiert das Regelmäßig, doch geht die Auslastung...
-
Forum: Programmieren allgemein
by TheGroudonx,
3. Sep 2014
Danke für die ganze Hilfe.
Stück für Stück bekomme ich das Endbild nun hin.
Das Locken und Unlocken ist noch die größte Herausforderung, denn wenn auch nur 1 lock oder unlock fehlt geht die ganze Anzeige meistens nichtmehr.
-
Forum: Programmieren allgemein
by TheGroudonx,
3. Sep 2014
Ich verwende schrittweises Kompilieren immer zur Fehlersuche.
Wenn dadurch in Verbindung mit Threads aber zusätzliche Fehler entstehen bzw. der Compiler aufhört weiterzuspringen dann ist Fehlersuche kaum möglich.
Werde wohl oder übel ohne die Funktion weitermachen müssen ...
-
Forum: Programmieren allgemein
by TheGroudonx,
3. Sep 2014
Sollte das bei dir keinen Fehler geben, liegt das Problem wohl am Delphi 7 Debugger.
Neben dem jetzigen Fehler habe ich eben einen bordbk70.dll access violation bekommen, der scheinbar mit Delphi 7 verbunden ist.#
Zudem mehrere schwere Fehler beim Debuggen, woraufhin Delphi geschlossen werden musste.
Das wäre eine Erklärung für das Desaster hier...Delphi 7 mag einfach noch keine Threads...
-
Forum: Programmieren allgemein
by TheGroudonx,
3. Sep 2014
Ich denke, ich kann das Problem (oder jedenfalls ein ähnliches) jetzt reproduzieren.
Man nehme einen Timer auf der Form 1 und gebe
Paintthread.zeichnen;
ein. Der Haltepunkt sollte darauf liegen.
Der Thread muss erstellt sein und seine Methode
-
Forum: Programmieren allgemein
by TheGroudonx,
3. Sep 2014
Meine Versuche mit dem Timer zeigen, dass der Fehler auftaucht, wenn sich der thread mit sleep(1) aktualisiert, jedoch nicht aufzutreten scheint, wenn er sich mit sleep(1000000) aktualisiert, also nichts tut.
Das deutet darauf hin, dass die beiden threads indirekt miteinander kollidieren, auch wenn sie sich niemals Prozeduren oder deklarierte Variablen teilen.
Wie das möglich ist, oder wie sich...
-
Forum: Programmieren allgemein
by TheGroudonx,
3. Sep 2014
Der Timer ist aus.
-
Forum: Programmieren allgemein
by TheGroudonx,
3. Sep 2014
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, ExtCtrls, UThread;
type
TForm1 = class(TForm)
-
Forum: Programmieren allgemein
by TheGroudonx,
3. Sep 2014
Dann ist es entweder die Delphi Version, die den Unterschied macht, oder, was wahrscheinlicher ist, das Durchsteppen wurde nicht so durchgeführt, wie es muss, damit der fehler auftaucht.
Zum Nachvollziehen habe ich ein Video
gelinkt
Es zeigt das Kompilieren, welches am Haltepunkt (Thread-constructor) stoppt, und daraufhin mit F7 gedrückt weiterläuft.
PS: Deine Exception wird nicht angezeigt
-
Forum: Programmieren allgemein
by TheGroudonx,
3. Sep 2014
Der normale Mainthread-Context erstellt den Thread(TThread)-von da aus läuft alles von selbst weiter.
Der Thread(TThread) ist in einer separaten Unit.
Er(Der Thread) arbeitet seine Execute Methode ab.
Dabei ruft er die Synchronize(Zeichnen) Prozedur auf, durch welche der Mainthread-Context die Zeichen-Routine ausführt.
Dies führt nach Wiederholungen beim Durchsteppen zu einem...
-
Forum: Programmieren allgemein
by TheGroudonx,
3. Sep 2014
Ich nahm an, dass bei einer Kombination aus dem üblichen Mainform-Prozess und einem Thread keine Verwechslungen durch Vokalwahl auftreten könnten.
Meines Wissens führt der Thread alles selbstständig aus, was über seine Routine Execute verbunden ist und kein Synchronize ist.
Jedenfalls ruft der Hauptprozess eine leere Methode des Threads auf, was zu einem Fehler führt. (siehe oben!)
-
Forum: Programmieren allgemein
by TheGroudonx,
3. Sep 2014
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...
-
Forum: Programmieren allgemein
by TheGroudonx,
3. Sep 2014
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:
procedure TPaintThread.Execute;
begin
While...
-
Forum: Programmieren allgemein
by TheGroudonx,
1. Sep 2014
Ups, habe vergessen die 2te Bitmap (original) mit zu locken/unlocken...
Das hat scheinbar einen großen Effekt gehabt.
-
Forum: Programmieren allgemein
by TheGroudonx,
1. Sep 2014
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...
-
Forum: Programmieren allgemein
by TheGroudonx,
1. Sep 2014
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 ._.
-
Forum: Programmieren allgemein
by TheGroudonx,
1. Sep 2014
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. :?
-
Forum: Programmieren allgemein
by TheGroudonx,
1. Sep 2014
Was mich nur noch verwundert ist, dass wenn ich den Thread durchsteppe, nach wie vor access-violations bzw auch einmal eine eexternalexception auftreten, während Threadeigene Bitmaps bearbeitet werden, auf die nicht von ausserhalb des Threads zugegriffen wird, welche auch 100% existieren. Dabei variiert das Tempo, in dem man zur nächsten Codezeile springen kann, stark, was normalerweise nicht...
-
Forum: Programmieren allgemein
by TheGroudonx,
1. Sep 2014
Das war ja auch meine Anfangsidee. Leider funktionierte das "abholen" nicht.
-
Forum: Programmieren allgemein
by TheGroudonx,
1. Sep 2014
In der Tat passiert eine ganze Menge arbeit, das geht aus dem Beispiel jetzt nicht wirklich hervor.
Es sind viele Berechnungen und Zeichnungen, die zu einem Bild zusammengefügt werden, welches dann kopiert werden soll.
Da für jedes Bild alles neu berechnet werden muss ist ein thread sinnvoll.
Soweit ich das sehe wird nur der Synchronize-Teil von der Hauptform ausgeführt während die Berechnung...
-
Forum: Programmieren allgemein
by TheGroudonx,
1. Sep 2014
Die neue Art sieht so aus:
Aufruf:
procedure TForm1.FormCreate(Sender: TObject);
begin
Paintthread := TPaintThread.create(false);
Paintthread.Image := Image1;
end;
Thread:
-
Forum: Programmieren allgemein
by TheGroudonx,
1. Sep 2014
Hab mir jetzt mal eine Unit mit Synchronize angeschaut, scheint auf den ersten Blick zu funktionieren.
Den Quelltext von Sir Rufo habe ich versucht zu kompilieren, aber Delphi 7 kennt kein "System.Generics.Collections" (hoffe ist nicht wichtig).
Nach der Anpassung der Unit-Bezeichnungen kommt leider schon bei Zeile 14
constructor Create( AWidth, AHeight : Integer );
die nächste...
-
Forum: Programmieren allgemein
by TheGroudonx,
1. Sep 2014
Ich möchte Bilder in einem Thread zeichnen lassen und diese dann auf die Form kopieren.
Dabei soll die CPU-Auslastung in den Thread geschoben werden.
-
Forum: Programmieren allgemein
by TheGroudonx,
1. Sep 2014
Wenn ich nun statt einem rechteck eine bitmap malen will, sollte logischerweise die Malfläche wieder gelockt werden.
Das zu malende Bild muss aber unlocked werden, oder?
MyBild.Canvas.lock;
nochnbild.Canvas.unlock;
MyBild.Canvas.Draw(0,0,nochnbild);
nochnbild.Canvas.lock;
-
Forum: Programmieren allgemein
by TheGroudonx,
1. Sep 2014
Danke für die hilfreichen Infos, Medium.
Ich hatte bis jetzt die Erfahrung, dass Bitmaps, die vom Thread erstellt und benutzt werden, Fehlermeldungen hervorrufen können, was durch .unlock vor dem Zeichnen im Thread nichtmehr geschah. Von daher sollte die Bitmap entweder nicht standardmässig auf unlocked stehen oder die routine macht noch andere relevante dinge. Jedenfalls werde ich das locken...
