Timer in einer Unit

[BadenPower]

Zitat:

Zitat von Sir Rufo (Beitrag 1294143)

Kein hWnd und nIDEvent passt zu keinem existierenden Timer, dann gibt es eine neue Timer ID.

Also wird nicht generell ignoriert.

Also meine Hilfe sagt, dass IDEvent ignoriert wird, wenn das Handle Null ist.

Zitat:

nIDEvent
[in] Specifies a nonzero timer identifier. If the hWnd parameter is NULL, this parameter is ignored.

Aber dann kommt die ID für KillTimer nicht durch IDEvent. sondern durch den Rückgabewert der Funktion SetTimer().

[Sir Rufo]

Zitat:

Zitat von BadenPower (Beitrag 1294144)

Zitat:

Zitat von Sir Rufo (Beitrag 1294143)

Kein hWnd und nIDEvent passt zu keinem existierenden Timer, dann gibt es eine neue Timer ID.

Also wird nicht generell ignoriert.

Also meine Hilfe sagt, dass IDEvent ignoriert wird, wenn das Handle Null ist.

Zitat:

nIDEvent
[in] Specifies a nonzero timer identifier. If the hWnd parameter is NULL, this parameter is ignored.

Aber dann kommt die ID für KillTimer nicht durch IDEvent. sondern durch den Rückgabewert der Funktion SetTimer().

Ich weiß ja nicht wo du schaust, aber ich schaue mir
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
an.

Zitat:

If the hWnd parameter is NULL, and the nIDEvent does not match an existing timer then it is ignored and a new timer ID is generated.

Und ja, wenn dort steht, dass es sich um einen IN Parameter handelt, dann erwarte ich nicht, dass darüber etwas zurückkommt, denn dann wird das als OUT Parameter bezeichnet.

Und zudem steht auch da, was der Rückgabewert bedeutet: Die Timer ID

[HolgerX]

Also, Beispiel:

Wenn Du 3 unterschiedliche Timer benötigst, dann brauchst du

a)
3 verschiedene Handles, dann können die IDs gleich sein aber auf jeden Fall > 0.

oder

b)
bei gleichem oder keinem Handle, z.B. dem Application.Handle, 3 verschiedene IDs

Windows MUSS den Timer eindeutig identifizieren können und nutzt hier eine Kombination aus dem Handle UND der ID.

Wenn Du bereits einen Timer mit der gleichen Kombination von Handle und ID erzeugt hast und das SetTimer nochmals mit den gleichen Werten aufrufst, dann wird KEIN neuer Timer angelegt, sondern bei dem bestehendem Timer NUR der Interval und ggf. die Funktion ausgetauscht.

Nur wenn Du eine NEUE Kombination von Handle und ID verwendest, wird ein neuer Timer erzeugt.

So, hoffe nun die Abhängigkeit zwischen Handle und ID verdeutlicht zu haben.. :wink:

[BadenPower]

Zitat:

Zitat von Sir Rufo (Beitrag 1294150)

Ich weiß ja nicht wo du schaust, aber ich schaue mir
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
an.

Nachdem ich durch Deinen Post #10 nicht mehr ganz sicher wahr, ob mein Erinnerungsvermögen nicht doch im Stich gelassen hatte, habe ich das getan, ws wir immer und immer wieder predigen und die Delphi-Wunderwaffe gezückt, in dem ich die F1-Taste betätigt habe.

Das Ergebnis war das, welches ich gepostet habe.
Dies entspricht allerdings inhaltlich nicht exakt dem, welches ich aus Deinem Link zu MSDN entnehmen kann.

Vielleicht sollte man die F1-Taste doch deaktivieren und nicht mehr erwähnen.

Zitat:

Zitat von Sir Rufo (Beitrag 1294150)

Und zudem steht auch da, was der Rückgabewert bedeutet: Die Timer ID

Das war ja auch nur eine vorsorgliche Antwort darauf wo ich die TimerID herbeziehe, wenn der, wie ich annahm, Parameter nIDEvent, den man selbst angibt und welchen man normal mit KillTimer() benutzt, ignoriert werden würde.

[Popov]

Was kann man abschließend zu dem ersten Code sagen? Ist der Ok, bzw. sauber, oder fehlt da noch was? Wie gesagt, im TTimer Klasse wird da noch nach WM_TIMER geprüft, nur erkenne ich die Notwenigkeit nicht. Kann aber an mir liegen.


Unabhängig dessen, weil ich dann doch unsicher war, habe ich nach weitere Methoden getestet. Dieses Mal habe ich den Tipp befolgt doch den TTimer selbst zu nehmen. Nur wie gesagt, es soll ohne Formular funktionieren, bzw. in einer Unit.

Ich hab zwei Beispiele mit TTimer. Der eigentliche Aufwand dreht sich eigentlich nur um OnTimer.

Delphi-Quellcode:

type
  TMyTimer = class(TTimer)
  public
    procedure TimerTick(Sender: TObject);
  end;

var
  MyTimer: TMyTimer;
  a: Integer = 0;

procedure TMyTimer.TimerTick(Sender: TObject);
begin
  Inc(a);
end;

procedure MyTimerCreate;
begin
  MyTimer := TMyTimer.Create(nil);
  with MyTimer do
  begin
    Interval := 1000;
    Enabled := True;
    OnTimer := TimerTick;
  end;
end;

procedure MyTimerFree;
begin
  MyTimer.Free;
end;

initialization
  MyTimerCreate;

finalization
  MyTimerFree;

end.

Andere Variante. Die Idee fand ich im Internet. Ich weiß nicht ob die besser ist als die erste, sie ist zunindest etwas anders:

Delphi-Quellcode:

type
  TEventHandlers = class
    procedure TimerTick(Sender : TObject);
  end;

var
  MyTimer: TTimer;
  EventHandlers : TEventHandlers;
  a: Integer = 0;

procedure TEventHandlers.TimerTick(Sender: TObject);
begin
  Inc(a);
end;

procedure MyTimerCreate;
begin
  EventHandlers := TEventHandlers.Create();

  MyTimer := TTimer.Create(nil);
  with MyTimer do
  begin
    Interval := 1000;
    Enabled := True;
    OnTimer := EventHandlers.TimerTick;
  end;
end;

procedure MyTimerFree;
begin
  EventHandlers.Free;
  MyTimer.Free; 
end;

initialization
  MyTimerCreate;

finalization
  MyTimerFree;

end.

Das sind jetzt also drei Varianten. Welche ist die Beste für Timer in einer Unit ohne Formular?

[stahli]

Zitat:

Zitat von Popov (Beitrag 1294247)

Ich hab zwei Beispiele mit TTimer. Der eigentliche Aufwand dreht sich eigentlich nur um OnTimer.

Delphi-Quellcode:

type
  TMyTimer = class(TTimer)
  public
    procedure TimerTick(Sender: TObject);
  end;
...

In dem Sinne wollte ich Dir gestern eigentlich antworten, hatte das dann aber verworfen weil ich meinte, Du suchst eine andere Lösung (ohne TTimer).

[Popov]

Zitat:

Zitat von stahli (Beitrag 1294250)

In dem Sinne wollte ich Dir gestern eigentlich antworten, hatte das dann aber verworfen weil ich meinte, Du suchst eine andere Lösung (ohne TTimer).

Eigentlich suche ich auch eine Lösung ohne TTimer. Der Grund ist aber weniger eine Abneigung gegen den TTimer, als die Frage ob Komponenten, selbst wenn sie nicht sichtbar sind, in einer reinen Unit etwas zu suchen haben?

[EWeiss]

Zitat:

Zitat von Popov (Beitrag 1294252)

Zitat:

Zitat von stahli (Beitrag 1294250)

In dem Sinne wollte ich Dir gestern eigentlich antworten, hatte das dann aber verworfen weil ich meinte, Du suchst eine andere Lösung (ohne TTimer).

Eigentlich suche ich auch eine Lösung ohne TTimer. Der Grund ist aber weniger eine Abneigung gegen den TTimer, als die Frage ob Komponenten, selbst wenn sie nicht sichtbar sind, in einer reinen Unit etwas zu suchen haben?

Warum vermischst du dann TTimer mit TMMTime?
Die API Lösung basiert auf MMSystem (TMMTime)

gruss

[BadenPower]

Zitat:

Zitat von Popov (Beitrag 1294252)

Der Grund ist aber weniger eine Abneigung gegen den TTimer, als die Frage ob Komponenten, selbst wenn sie nicht sichtbar sind, in einer reinen Unit etwas zu suchen haben?

Eine Komponente ist doch auch nur eine stink normale Klasse, wie z.B. TStringList, welcher die zusätzliche Möglichkeit gegeben wurde auf der Form platziert zu werden, damit sie automatisch erstellt wird und man Werte im OI beabeiten kann.

[Popov]

@BadenPower

Ist schon klar. Man kann aber auch die Verandatür öffnen und sein Auto im Wohnzimmer parken. Gehen tut es, womit die Parkplatzprobleme vorbei wären, man fragt sich aber trotzdem stets ob es die feine saubere Art ist.