Gespräch simulieren??

[himitsu]

Ich würde aber nicht ständig am Timer rumspielen.
Jedesmal wenn das Intervall geändert wird, oder wenn man das Enabled ändert, wird intern ein verstecktes Fenster erstellt und darauf ein Timer erzeugt. (bei Änderungen wird vorher alles wieder gelöscht)

z.B. Timer.Intervall auf 1000 und dann entspricht jede Phase der abgelaufenen Sekunde.

Delphi-Quellcode:

procedure TfrmMain.Timer1Timer(Sender: TObject);
begin
  case Phase of
    1: begin
         //erstes Panel beschriften, sichtbar, Refresh
       end;
    5: begin
         //zweites Panel beschriften, sichtbar, Refresh
       end;
    17: begin
         //drittes Panel beschriften, sichtbar, Refresh
       end;
    x: begin
         //beliebig erweiterbar
         
         Timer1.Enabled := False;//und beim Letzen den timer ausschalten
       end;
  end;
  inc(Phase);
end;

[Thom]

@Progman:
Ja, ganau: Das wäre eine universelle Lösung, bei der der Rest der Anwendung auch noch bedienbar bleibt und sogar geschlossen werden könnte, ohne Zugriffsverletzungen durch Application.ProcessMessages befürchten zu müssen.

@MrSpock:
Die Methode Update greift nur, wenn das Steuerelement komplett oder zumindest der betreffende Teil in die Updateregion aufgenommen wurde. Beim Label geschieht das automatisch, wenn die Beschriftung geändert wurde. Anders sieht es bei selbstgezeichneten Elementen - wie zum Beispiel einer PaintBox aus. Hier muß der Bereich explizit zur Updateregion hinzugefügt werden. Der Einfachheit halber kann man das über die Methode Invalidate bewerkstelligen:

Delphi-Quellcode:

  PaintBox1.Invalidate;
  PaintBox1.Update;

Beide Anweisungen lassen sich auch mit PaintBox1.Repaint zusammenfassen.
Ein kleines Beispiel dazu (ein Button und eine PaintBox auf dem Formular und die Unit AnonymousMethodsTools.pas aus dem Google Maps Framework einbinden):

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
const
  Radius = 5;
var
  x: Integer;
begin
  with PaintBox1 do
  begin
    OnPaint:=MakeEvent(
      procedure(Sender: TObject)
      var
        y: Integer;
      begin
        y:=Round(-4*(Radius-Height)/Sqr(Width)*Sqr(x-Width/2)+Radius);
        Canvas.Brush.Color:=clRed;
        Canvas.Ellipse(x-Radius,y-Radius,x+Radius,y+Radius);
      end);
    for x:=-Radius to Width+Radius do
    begin
      Repaint;
      Sleep(10);
    end;
    ReleaseEvent(OnPaint);
    OnPaint:=nil;
  end;
end;

Hier wird einfach eine rote Kugel (genauer gesagt: ein Kreis) in einer parabelförmigen Bahn durch die Gegend geschossen. Auch hier werden die Veränderungen auf dem Bildschirm sichtbar, obwohl ProcessMessages nicht aufgerufen wird. Allerdings ist die Anwendung in dieser Zeit natürlich nicht bedienbar.

Ersetzt man jetzt die Schleife mit

Delphi-Quellcode:

    [...]
    for x:=-Radius to Width+Radius do
    begin
      Invalidate;
      Application.ProcessMessages;
      Sleep(10);
    end;
    [...]

kommt es zu Zugriffsverletzungen, da jetzt der Anwender die Möglichkeit hat, den Button während der Ausführung der Methode erneut zu betätigen. Damit sind dann zusätzliche Sicherungsmaßnahmen notwendig (zum Beispiel Button während der Ausführung deaktivieren oder ein Flag mit Abbruchbedingung).

@himitsu:
Wo steht das mit dem internen Fenster?
Im Quelltext von TTimer.UpdateTimer in der Unit ExtCtrls steht lediglich ein Aufruf von KillTimer und SetTimer (beides API-Funktionen) mit dem selben Fenster-Handle...

[himitsu]

Schau dir mal das Handle an, welches für KillTimer/SetTimer verwendet wird.

Das Problem dabei ist, daß Timer über eine ID direkt auf einem Formular sitzen. Leider gibt es keine Möglichkeit, um rauszufinden ob und welche IDs belegt sind.
Darum wurde hier einfach für jeden Timer ein eine eigene Form genommem und darauf wird dann stur mit der ID 1 gearbeitet.

[edit]
Komisch, mir war so, als wenn das Fenster freigegeben wird, wenn es nicht mehr nötig ist.
OK, dann isses doch nicht so schlimm.
Aber wenn man die Zeit halbwegs synchron halten will, wäre es dennoch nicht so schlecht, den Timer laufen zu lassen.
- Um die Zeit, welche vom Auslösen des Timer-Events bis zu dessen Bearbeitung vergangen ist und dazu noch die Zeit zwischen Diasable und Enable (des Timers) wird der nächste Aufruf verzögert.

[Progman]

Zitat von himitsu:

.....
Aber wenn man die Zeit halbwegs synchron halten will, wäre es dennoch nicht so schlecht, den Timer laufen zu lassen.
- Um die Zeit, welche vom Auslösen des Timer-Events bis zu dessen Bearbeitung vergangen ist und dazu noch die Zeit zwischen Diasable und Enable (des Timers) wird der nächste Aufruf verzögert.

Das zwischenzeitliche Disablen des Timers hat eigentlich nur den Zweck, eine eventuell länger dauernde Befehlsfolge/Abarbeitung im Case-Block zu berücksichtigen, um zu verhindern, dass der nächste Timer-Event zu früh eintritt. Das betrifft aber nur Befehlsfolgen, die wirklich länger dauern als der Timer-Interval, was eigentlich nur selten vorkommen sollte.
Es könnte im hier zutreffenden Fall durchaus weggelassen werden