PaintBox.Paint startet immer wieder neu

[SteffenSchm]

Aber ist es nicht so, dass der Debugger immer mal zwischendurch abfragt, ob irgendwelche Ereignisse eingetreten sind (z.B. Drücken der Pausentaste), welche bearbeitet werden müssen. Und kann das nicht der Grund dafür sein, dass mit Debugger die Zeichnung (wenn auch langsam) fertig gezeichnet wird, während ohne Debugger immer wieder von vorn angefangen wird.

Es muss doch einen Grund geben, warum das mit Debugger funktioniert und ohne nicht!

[jfheins]

Zitat:

Zitat von SteffenSchm (Beitrag 1488207)

Ich habe das Programm jetzt mit Debugger laufen lassen und dabei tritt das Problem nicht auf.
Kann es sein, dass ich innerhalb der langen Schleife in der Methode PaintBox.Paint die Steuerung mal an das Programm zurückgeben muss?

Neee. Aber es sollte halt auch keine lange Schleife sein. Falls die Grafik zu aufwändig ist, evtl. auf ein Bitmap malen und im Paintbox OnPaint nur das Bitmap kopieren.

Oder die Daten runter samplen. Es bringt ja nix, pro Pixel 3 Datenpunkte einzuzeichnen ;-)

[Andreas13]

Zitat:

Zitat von SteffenSchm (Beitrag 1488162)

Das Problem ist, dass die Zeichnung nie fertiggestellt wird. Nach einigen Sekunden wird das Bild jeweils verworfen und der Aufbau beginnt von vorn.

Hallo Steffen,
ich hatte vor einigen Monaten ein ähnliches Problem mit einer DLL für Excel. Nach dem Schließen von Excel, wurde dieses immer wieder neu gestartet, aber nur, wenn ich die DLL als Release kompiliert hatte. Im Falle von Debug trat der Fehler merkwürdigerweise nicht auf, so ähnlich wie bei Dir.
Der Fehler lag bei mir daran, daß ich an einer Stelle die Längen von Excel-LongInt und Dalphi-Integer falsch angepaßt hatte.
Es könnte sein, daß dies Dir vielleicht etwas weiterhilft, vermutlich nicht...
Gruß, Andreas

[SteffenSchm]

Ich habe jetzt in die Schleife die innerhalb PaintBox.Paint aufgerufen wird die folgende Zeile eingefügt:

Delphi-Quellcode:

Application.ProcessMessages;

Jetzt schafft es das Programm die Zeichnung zu Ende zu zeichen ohne immer wieder von vorn anzufangen.
Auch wenn ich nicht weiß warum, so scheint es doch etwas damit zu tun zu haben.

Schönen Abend und Danke für die Hinweise und Eure Zeit!

Steffen

[Uwe Raabe]

Damit hast du das Problem aber nur kaschiert ohne es zu verstehen und zu lösen. Beim nächsten Fehler sind deine Probleme dann nur noch größer.

[Michael II]

Ohne Code von dir kann nur spekuliert werden. Zeig doch mal ein Minimalbeispiel.

Wie bereits erwähnt wurde: Wenn du den User nicht beim Zeichnen der Polyline zuschauen lassen willst, dann male deine Grafik auf eine Bitmap und gib diese am Ende der Berechnung aus.

Da die Berechnung der Grafik länger dauert: Nutze einen separaten Thread für die Berechnung, damit dein Programm während der Berechnung (zum Beispiel Verschieben des Fensters etc.) reagiert.

Wenn du eine Bitmap verwendest, kannst du im Ereignis "neu malen" (z.Bsp. wenn ein User ein anderes Fenster über dein Fenster zieht - oder wenn dein Fenster über den Bildschirmrand verschoben wird und zurück) nur die bereits berechnete Bitmap neu ausgeben. Sonst musst du wieder alles rechnen und deine Kundinnen und Kunden nutzlos warten lassen...

Wenn du in deine PaintBox ein Image legst und die berechnete Bitmap dort rein legst, dann malt sich das Ding sogar selber.

Wenn du in deinem Programm nach dem Grund (IDE so, nicht IDE anders) suchen willst, dann könntest du zum Beispiel ein TApplicationsEvents auf deine Form setzen und aufzeichnen was unter OnMessage rein kommt. Sehr wahrscheinlich würdest du rasch sehen, was anders ist. (Du könntest nat. auch ein "externes" Tool verwenden.)


In deinem Ereignis Handler Application.ProcessMessages; aufzurufen ist nicht mal für ein Hobby Programm... aber das ist ein zu weites Feld.

[himitsu]

Aber wie gesagt, damit kann es passieren, dass dein Zeichnen (OnPaint) während der Arbeit neu gestartet wird und es so auch in einer Eindlosschleife einem Stacküberlauf endet.

Schlimmer wird es dann, wenn nicht nur mit lokalen Variablen gearbeitet wird, womit es dann zwischen den verschiedenen Ausführungen Überschneidungen geben kann. (z.B. das eingebettete Zeichnen ändert einen globalen Zähler/Liste und wenn es in den ersten Aufruf zurück kommt hat sich dort mitten drin in der Schleife der Zustand geändert und z.B. ein Index oder Abbruchbedingung raucht ab oder wird nie erreicht)

Mit ProcessMessages muß man echt aufpassen, da es Doppelausführungen geben kann.
z.B. in einem Button eine Schleife, die Zahlen in ein Memo ausgibt. und mitten im ProcessMessages kannst du ja nochmals auf den Button drücken, während das erste OnClick noch nicht fertig war.

[himitsu]

OnMessage sind aber ausschließlich von PostMessage, was in der MessageQueue landete.
SendMessage kommt dort nicht vorbei. (dafür bräuchte man einen andren Hook)

Ja, für Vieles kann es dennoch einen Hinweis geben.
Aber beachte, dass wenn man z.B. die Messages in ein Memo loggt, das wiederrum Messages auslöst, was das Ergebnis verfälschen kann.

[Michael II]

Zitat:

Zitat von himitsu (Beitrag 1488223)

OnMessage sind aber ausschließlich von PostMessage, was in der MessageQueue landete.
SendMessage kommt dort nicht vorbei. (dafür bräuchte man einen andren Hook)

Ja, für Vieles kann es dennoch einen Hinweis geben.
Aber beachte, dass wenn man z.B. die Messages in ein Memo loggt, das wiederrum Messages auslöst, was das Ergebnis verfälschen kann.

Er braucht's ja nicht für ein Memo.
Ich bin ziemlich sicher, dass es reicht und er den Unterschied dort abgreifen kann.

Und nun schreib ich's halt doch ;-): Zu deinem #7: Es ist ganz sicher auch auf deinen Kisten nicht schneller, wenn du direkt Linie für Linie in die Paintbox (Grafikkarte) malst, als wenn du zuerst im RAM alles in eine Bitmap zeichnest und dann einmal raus auf die Grafikarte schreibst. Auf meinem Uraltnotebook benötigt die direkte Paintboxkmalerei auf eine HD-Form (PaintBox alClient) für 1 Mio Zufallslinien 30 Sekunden. Wenn ich die 1 Mio Zufallslinien in die Bitmap zeichne und dann raus in die Paintbox schreibe "kostet" das 3 Sekunden.

[himitsu]

War nur als Hinweis, falls er es sich "anzeigen" will, um es im laufenden Programm sehen zu können. :angle:

In ein Log oder OutputDebugStrings (wenn im Debugger, in dessen MessagesFenster, aber aufpassen, ist bissl langsamer) ginge natürlich auch.


Wer (zu)viel Misst, misst manchmal auch Mist.