Countdown auf Panel anzeigen

freakC++

Hallo zusammen,
ich habe folgendes Problem: Ich möchte einen Countdown auf einem Panel anzeigen, doch das funktioniert nicht ganz so wie ich es will. Beim Panel wird nur die 0, also die letzte Zahl eingezeigt, wenn der Countdown zu Ende ist. Wenn ich jedoch den Countdown auf einem Button anzeigen lassen, dann funktioniert alles, also der vollständide Countdown ist sichtbar. Warum funzt das mit dem Panel nicht:

for (int i = Zahl; i > -1; i--)
  {
   Form1->Panel1->Caption = i; //Wenn ich anstatt eines Panels einen Button
   Sleep (500);                 //nehme, ist der Countdown vollständig sichtbar
  }

Vielen Dank für eure Hilfe
lg, freakC++

akari

Hallo

for (int i = Zahl; i > -1; i--)
  {
   Form1->Panel1->Caption = i; //Wenn ich anstatt eines Panels einen Button
   Application->ProcessMessages(); // Sorgt dafür das Änderungen verarbeitet werden
   Sleep (500);                 //nehme, ist der Countdown vollständig sichtbar
  }

Oder besser gleich TTimer nehmen.

bis bald
akari

freakC++

Hallo akari,
vielen Dank für deine Lösung. Ich kannte diese Methode noch nicht. Kann man vielleicht sagen, dass sie eine Aktualisierung durchführt (oder wie du gesagt hast, Änderungen verarbeitet)???

Klar, mit TTImer gehts auch.

Was ist denn der große Unterschied zwischen TButton und TPanel?

Vielen Dank für deine Hilfe
lg, freakC++

Multi

TButton ist ein Button 'Knopf' auf den man drücken kann
und
TPanel ist eine '3D'-Textanzeige

Linnea

TPanel ist auch eine Art "Kontainer" für visuelle Komponenten, um Komponenten anzuordnen und z.B. als Block zu verschieben

akari

Hallo

freakC++ schrieb:

Was ist denn der große Unterschied zwischen TButton und TPanel?

Der Unterschied in Bezug auf dieses Thema dürfte sein, das TButton bei einer Änderung der Caption-Eigenschaft von selbst die Aktualisierung aufruft, während TPanel das eben nicht macht.

Ich kannte diese Methode noch nicht. Kann man vielleicht sagen, dass sie eine Aktualisierung durchführt (oder wie du gesagt hast, Änderungen verarbeitet)???

Genaugenommen sorgt diese Methode dafür das alle noch anstehenden Windows-Messages sofort verarbeitet werden. Normalerweise wird damit gewartet bis die (VCL-) Methode wieder verlassen wird. Dadurch werden alle Aktualisierungen der wirklichen Anzeige beim TPanel auf die lange Bank geschoben (genauer gesagt die Message-Queue), und erst am Ende der Methode auf einen Rutsch abgearbeitet, wovon du als Benutzer aber nur den Endzustand bemerkst.

bis bald
akari

Finger weg von Application->ProcessMessages !
Damit handelt man sich oft mehr Probleme ein, als einem lieb ist. Wenn der Benutzer auf auf das "Schliessen" Symbol des Fensters klickt , während der Countdown läuft, rappelt´s gewaltig. Nach Aufruf von ProcessMessages ist das Fenster dann weg, aber die Schleife wird noch zu Ende durchlaufen, was zu undefiniertem Verhalten führt, weil das Fensterobjekt, in dem die Schleife läuft, nicht mehr gültig ist.

Gruss,
Doc

Kolumbus

Hallo,

schau Dir am Besten mal die Methoden von TPanel in der Hilfe an... PanelX->Repaint()...

MfG

PS: Es lohnt sich immer, erstmal die Eigenschaften und Methoden einer Komponente, welche man noch nicht bzw. noch nicht oft benutzt hat, in der Hilfe anzuschauen - da bekommt man einen guten Überblick was die Komponente kann und wofür man sie einsetzen könnte.

DocShoe schrieb:

Finger weg von Application->ProcessMessages !
Damit handelt man sich oft mehr Probleme ein, als einem lieb ist. Wenn der Benutzer auf auf das "Schliessen" Symbol des Fensters klickt , während der Countdown läuft, rappelt´s gewaltig. Nach Aufruf von ProcessMessages ist das Fenster dann weg, aber die Schleife wird noch zu Ende durchlaufen, was zu undefiniertem Verhalten führt, weil das Fensterobjekt, in dem die Schleife läuft, nicht mehr gültig ist.

Glaub ich nicht. Die Anwendung sollte weiterlaufen, bis die Schleife beendet ist und erst dann sollte sich die Anwendung beenden.

Joe_M. schrieb:

Glaub ich nicht. Die Anwendung sollte weiterlaufen, bis die Schleife beendet ist und erst dann sollte sich die Anwendung beenden.

Hab an genau diesem Problem mal zwei Tage lang geknabbert. Dialog mit Fortschrittsbalken, der eine Datei einliest. Zwischen zwei Leseoperationen wurde ProcessMessages aufgerufen, um den Cancel Button zu behandeln. Das Ganze ging genau so daneben, wie ich es oben beschrieben habe.
Möglicherweise spielt der Kontext noch eine Rolle, wenn der Owner des Fensters noch lebt, ist das Fensterobjekt wahrscheinlich immer noch gültig. Ich habe das Fensterobjekt in einen boost::scoped_ptr gepackt, damit war das Fensterobjekt zerstört, nachdem der scoped_ptr out of scope ging.
Das sind aber auf jeden Fall Dinge, die man bei der Benutzung von ProcessMessages betrachten sollte.

Gruss,
Doc

Nun ja, Du musst zugeben, dass das ein 'tragisches Einzelschicksal' war.

So lange man bei reinen VCL-Funktionalitäten bleibt, sollte ProcessMessages keine Probleme bereiten. Wenn man der VCL allerdings in die Speicherverwaltung 'pfuscht', muss man tatsächlich mit so etwas rechnen. Das Problem war also nicht der ProcessMessages-Aufruf, sondern die Veränderung der Objekteigentümer und das daraus resultierende zu frühe Löschen der Objekte.

Aber irgendwo hast Du auch recht, sobald man gezwungen ist, ProcessMessages einzusetzen, sollte man das Konzept zumindest noch einmal überdenken...

Bin mir jetzt nicht mehr ganz sicher, was damals schiefgegangen ist... konnte es jedenfalls auf die Schnelle nicht mehr reproduzieren. Wahrscheinlich bin ich wieder der Einzige auf der Welt, der genau dieses Problem hat. Genau wie mit meinen anderen Problemen :D.
Ich bin kein grosser Freund der VCL Speicherverwaltung, bei der Tatsache, dass man alles auf dem Heap erzeugen muss stellen sich meine Nackenhaare auf.
Bei mir sind alle Eigentümer von VCL Objekten NULL, da ich immer genau weiss, ob und wie lange ich ein Objekt brauche. Ein Formular, dass dynamisch mit Application als Owner erzeugt wird kommt einem memory leak schon gefährlich nahe.

Gruss,
Doc