![]() |
TApplication.Processmessage
Hallo,
kann mir jemand sagen, wie ich das private TApplication.Processmessage aufrufen kann? Hintergrund: ich will in einer etwas zeitkritischen Anwendung auf ein Ereignis warten und während dessen nicht die MessageQueue blockieren - aber halt sofort nach Eintritt des Ereignisses mit meiner Procedure fortfahren und nicht, wie bei .ProcessMessages(), nachdem alle Messages aus der Queue abgearbeitet wurden mir schwebt so etwas wie TMyApplication = class(TApplication) .. vor, aber geht sowas? mfg |
AW: TApplication.Processmessage
Ich verstehe nicht ganz.
Wenn du verhindern möchtest, dass Windows deinen Prozess als 'reagiert nicht' einstuft, musst du die Message Queue nicht abarbeiten. Du musst sie nur ab und zu anfassen, ich glaube der WinAPI-Aufruf
Delphi-Quellcode:
reicht schon.
PeekMessage(..)
|
AW: TApplication.Processmessage
Zitat:
mir geht es darum, dass der auf das Ereigniss wartende Thread (eigentlich besser -> die wartende Aufgabe, da zZt. beides im VCL-Mainthread läuft) möglicherweise für mich eine höhere Priorität hat als die in der Queue wartenden Messages; also möchte ich, dass meine Aufgabe sofort nach Eintreffen des Ereignisses abgeschlossen wird und nicht erst, nachdem alle anderen Messages aus der Queue abgearbeitet wurden -- das ist währe genau das, was bei ProcessMessages passiert wenn man sich der Sache mal von der theoretschen Seite nähert kann man sagen: wenn es sinvoll ist ProcessMessages zu benutzen, könnte es auch sinnvoll sein ProcessMessage zu benutzen nur ist das Eine public und das Andere private und so kahm ich auf die Frage ob man ein abgeleitetes TApplication als Basis für eine Anwendung nutzen kann natürlich kann man das Problem auch mit einem separaten Thread lösen - aber das erhöht den Sync-Aufwand erheblich; und wie sich das dann erforderlichen Synchronize auf die Abarbeitungszeit auswirkt, weiss ich auch nicht mfg |
AW: TApplication.Processmessage
Man kann keine Ableitung von TApplication verwenden, da die verwendete Application-Instanz bereits im initialization-Abschnitt von Vcl.Controls instanziert wird (in InitControls). Selbst wenn das ginge, könntest du damit immer noch nicht auf die private Methode ProcessMessage zugreifen.
Du kannst aber alternativ HandleMessage aufrufen. Das ist eigentlich noch besser, da es die Hints und Actions aktualisiert und nebenbei auch noch das Synchronize der Threads durchlässt. |
AW: TApplication.Processmessage
>> könntest du damit immer noch nicht auf die private Methode zugreifen
Richtig, wo ist mein Kopf? >> Du kannst aber alternativ HandleMessage aufrufen Prima, das ist nah genug, da ich eh nicht mit OnIdle und TActions hantiere Danke |
AW: TApplication.Processmessage
Wie sieht's denn damit aus?
Delphi-Quellcode:
TMyApplication = class(TApplication)
public function ProcessMessage(var Msg: TMsg): Boolean; end; ... { TMyApplication } function TMyApplication.ProcessMessage(var Msg: TMsg): Boolean; begin inherited; end; Aufruf: procedure TForm1.Button1Click(Sender: TObject); var Msg: TMsg; begin TMyApplication(Application).ProcessMessage(Msg); end; |
AW: TApplication.Processmessage
yo, funzt -- das hat sich der Schöpfer aber auch anders gedacht;
als Verfechter der "Reinen Lehre" würde ich das als Bug klassifizieren schönes Forum : man bekommt nicht nur die richtige Antwort, sondern auch die die funktioniert mfg |
AW: TApplication.Processmessage
Besser finde ich da einen class helper zu benutzen. Denn der ist dafür gedacht, dass man im Kontext der Klasse handelt, während das mit der abgeleiteten Klasse eher ein Trick ist.
Delphi-Quellcode:
// das in eine Unit in der uses-Klausel oder in die eigene Unit:
TProcessMessageApplication = class helper for TApplication procedure DoProcessSingleMessage; end; procedure TProcessMessageApplication.DoProcessSingleMessage; begin Self.ProcessMessage; end; // und dann einfach benutzen: Application.ProcessMessage; |
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:22 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz