Forum: Win32/Win64 API (native code)
Delphi
by himitsu,
14. Okt 2014
Ein ProcessMessages unbedacht an einer ungünstigen Stelle bereitet mehr Probleme, als es löst.
In diesem Fall würde ich eher ein while PeekMessage(Msg, FWindowHandle, WM_TIMER, WM_TIMER, PM_REMOVE) do ; nach dem KillTimer einfügen, welches die Message(s) entfernt.
Forum: Win32/Win64 API (native code)
Delphi
by himitsu,
14. Okt 2014
Nach dem Freigeben der Form (genauer nach dem Freigeben des TTimer und dessen interne MessageOnlyForm) sollte eigentlich nichts mehr eintreffen.
Das Window, an welches das WM_TIMER geschickt wird, ist dann weg.
Wenn Fenster freigegeben werden, werden deren Messages aus der Queue entfernt, aber selbst wenn nicht, dann existiert das Fenster nicht mehr, welches diese Message empfangen und...
Forum: Win32/Win64 API (native code)
Delphi
by himitsu,
13. Okt 2014
:shock: Wenn ich manuell was in die Queue schiebe, dann wird das nicht verworfen.
Sehr verwirrend.
type
THackedTimer = class(TComponent)
private
FInterval: Cardinal;
FWindowHandle: HWND;
end;
Forum: Win32/Win64 API (native code)
Delphi
by himitsu,
13. Okt 2014
Bist du sicher, daß die Hilfe da stimmt?
Ich kann mich nicht erinnern jemals ein TimerEvent nach dem deaktivieren eines Timers bekommen zu haben.
Da wäre es doch statistisch eigenartig, wenn das niemals passiert wäre. :gruebel:
Hab mal schnell einen Test gemacht:
> zwei Timer und Memo auf der Form
procedure TForm2.FormCreate(Sender: TObject);
Forum: Win32/Win64 API (native code)
Delphi
by himitsu,
13. Okt 2014
Darauf kann man sich doch auch verlassen. :roll:
Wenn der Timer Disabled wird, dann wird sofort KillTimer aufgerufen und damit werden auch alle TimerEvents aus der MessageQueue entfernt, womit auch kein WM_TIMER mehr eintreffen kann.
Und da man auf solche Komponenten niemals aus anderen Threads zugreift, kann es auch nicht zu Problemen kommen.
Auch nicht bezüglich des nachfolgend...
