eigenartiges Verhalten von tlabel u. a. in for - to Schleifen

[DrUArn]

Hallo,

habe bisher immer 'mal beim Testen tlabels u.a. genutzt, um
Variablenänderungenzu beobachten (bisher in Turbodelphi), z.B.

Delphi-Quellcode:

procedure TForm2.Button1Click(Sender: TObject);
var
  I: Integer;
begin
for I := 0 to 10 do
 begin
    caption:=inttostr(i);
    Button2.Caption:=inttostr(i);
    edit1.text:=inttostr(i);
    label1.Caption:=inttostr(i);
    RichEdit1.Lines.Add(inttostr(i));
    sleep(250);
 end;
end;

Jetzt beobachte ich, daß tform.caption und Button2.Caption die i's alle darstellen, bei den anderen wird nur i= 10 dargestellt - also das Ende der Schleife. Zwischendurch erfolgt keine Neudarstellung.
Manchmal -insbesonder wenn ich tbutton benutze, kommt kurzfritig - "Das programm antwortet nicht" - mag aber an sleep liegen!

Weiß jemand, woran das liegt - irgendeine Delphi- oder Windows-Optimierung (Windows 7 64 bit) ? Muß man eine Neudarstellung erzwingen?

Mit gespannten Grüßen
Uwe

[mkinzler]

Erzwinge ein Neuzeichnen bzw. gib dem Formular die Chance

Application.ProcessMessages;

[Bjoerk]

in die Schleife vor Sleep:

Application.ProcessMessages; // Edit: Moderator war schneller

[DrUArn]

Das ist es,
mir war dieser Befehl entfallen!

danke , Bjoerk und Markus Kinzler!

Warum geht das ohne Application.ProcessMessages bei einigen "Darstellern", bei anderen nicht?

Es ist mir auch schon passiert aus einem trichedit.onchange - jeder tastenclick solte im Tlabel etwas darstellen - da wurde nur das erste Klicken bearbeitet und dann kein weiteres!

MfG
Uwe

[mkinzler]

Es wird keine Rechenzeit an den "zeichenen" Prozess abgegeben

[wicht]

Zitat:

Warum geht das ohne Application.ProcessMessages bei einigen "Darstellern", bei anderen nicht?

Bei welchen Komponenten funktioniert das denn? Weißt du ungefähr, wie das Messaging-System funktioniert/was ProcessMessages() tut? Ich konnte noch nie beobachten, dass das ohne klappt (in einer Situation wie von dir beschrieben).

[DrUArn]

Danke Markus,
verstehe ich - dann muß den Knecht eben zwingen!

Klappt aber auch nicht immer - benutzt man in einem etwas umfangreicheren Programm obiges Konstrukt, erweist sich tlabel als am stursten - will sich nicht neu darstellen, auch wenn man sofort nach der string-Zuordnung zu caption ein application.processmessages auslöst!

Hier beim Testen funktionierte es (siehe mein Delphi-Beispiel) in tform.caption und tbutton.caption (da nicht immer) ohne application.processmessages! - Wie dieses Messaging funktioniert, weiß ich auch nicht!

Danke für's mitdenken
Uwe

[mkinzler]

Das Fenter ( Ein Control ist unter Windows ein fenster) bekommt eine Nachricht gesendet, dass es sich neu Zeichnen soll.
Application.ProcessMessages; sogt dafür, dass alle untergeordneten "Fenster" ihre "Messages" abarbeiten.

[himitsu]

Einige Komponenten zeichnen sich bei jeder Kleinigkeit neu, was schonmal ganz schön Zeit fressen kann, wenn man Mehreres ändert.

TLabel sendet sich nur eine Nachricht "zeichne dich mal neu", welcher immer nur einmal in der Nachrichtenschlange landet.
Somit wird das Label quasi nur neu gezeichnet, wenn sich Form das nächtes Mal reagiert und alle bisherigen Nachrichten verarbeitet hat.
PS: Das TLabel kennt noch die Methoden Refresh und Repaint, um sich sofort neu zu zeichnen.

[DrUArn]

Zitat von himitsu:

Einige Komponenten zeichnen sich bei jeder Kleinigkeit neu, was schonmal ganz schön Zeit fressen kann, wenn man Mehreres ändert.
PS: Das TLabel kennt noch die Methoden Refresh und Repaint, um sich sofort neu zu zeichnen.

Hallo, in scheinbar rechenaufwändigen Programmen läßt sich als einziges tlabel von den genannten nicht einmal durch direktes Aufrufen von refresh oder repaint zu einer Neudarstellung vor Ende der Schleife zwingen!

Gruß Uwe