Nachricht global ausfiltern, noch vor dem Start des Hauptprogrammes

[hoika]

Hallo,
bei einem konvertibel NoteBook unter Windows 10 schmiert die DefWndProc in ntdll.dll ab.
Die Message ist immer 581 (WM_POINTERUPDATE), siehe auch dieser Thread.

http://www.delphipraxis.net/189031-m...l-gesucht.html

Wie kann ich die 581 global in meinem Programm ausknippsen.
Da es bereits noch vor dem Erzeugen des Hauptprogrammes passiert war (habe MadExcept-Auszug des Kunden),
müßte das noch vor der DPR passieren.

Ich habe also eine Unit geschrieben, die die erste in der DPR ist,
dann dort ein initialization rein.

Die Ursache des Absturzes will ich später analysieren (ich habe gar kein solches Notebook hier).

Da ich einige Komponenten habe, die die WndProc-Methode überschreiben,
wollte ich das an einer zentralen Stelle machen.

1. Ansatz
Application.OnMessage
ging gar nicht, dank einem ominösen TMultiCaster (unit AppEvnts), der das Application.OnMessage überschreibt.
siehe Ansatz 4

2. Ansatz
Application.HookMainWindow
macht genau das, also nur das MainWindow, sobald ein anderes Fenster/Form seine WndProc überschreibt, geht nix

3. Ansatz
Hooks
The CallWndProc hook procedure can examine the message, but it cannot modify it. After the hook procedure returns control to the system, the message is passed to the window procedure.
geht also auch nicht

4. Ansatz
AppEvents, leider wird die WndProc der Komponente vor der AppEvent-Methode aufgerufen

Was kann ich denn noch tun?

Hier mal mein Code, sieht etwas wild aus wegen den vielen Versuchen.

Delphi-Quellcode:

unit TouchScrollen;

interface

implementation

uses
  Windows, Messages, SysUtils, Forms, IniFiles,
  AppEvnts;

type
  TMessageObject = class
    procedure MyMessage(var Msg: TMsg; var handled: Boolean);
  end;

var
  _LocalIni: TIniFile;
  bKeinTouchScrollen: Boolean;
  MessageObject: TMessageObject;
  AppEvents: TApplicationEvents;

procedure TMessageObject.MyMessage(var Msg: TMsg; var handled: Boolean);
begin
  if Msg.message=581 then
  begin
    if bKeinTouchScrollen then
    begin
      handled := True;
    end;
  end;
end;

(*
function MyWndHook(nCode: Integer; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;
begin
  if bKeinTouchScrollen then
  begin
    if nCode=581 then
    begin
      Result := 0;
      Exit;
    end;
  end;

  Result := CallNextHookEx(FWndHook, nCode, wParam, lParam);
end;
*)

initialization

  MessageObject := nil;

  AppEvents := nil;

  _LocalIni:= TIniFile.Create(ExtractFilePath(Application.ExeName)+'My.Ini');
  try
    bKeinTouchScrollen := _LocalIni.ReadBool('General', 'NoTouchScroll', False);
    if bKeinTouchScrollen then
    begin
      MessageObject := TMessageObject.Create;

      //Application.OnMessage := MessageObject.MyOnGetMessage;
      //Application.HookMainWindow(MessageObject.MyHookFunc);
      //FWndHook := SetWindowsHookEx(WH_CALLWNDPROC, MyWndHook, 0, GetCurrentThreadId());

      //Application.m
      //procedure TMultiCaster.AddAppEvent(AppEvent: TCustomApplicationEvents);
      AppEvents := TApplicationEvents.Create(nil);
      AppEvents.OnMessage := MessageObject.MyMessage;
    end;
  finally
    _LocalIni.Free;
  end;

finalization

  //Application.OnMessage := nil;
  //FreeAndNil(MessageObject);

  //Application.UnHookMainWindow(MessageObject.MyHookFunc);

end.

[himitsu]

Ja, der Erfinder von TApplicationEvents sollte dafür erschossen werden.
Da erfindet der etwas, damit es keine Konflikte mehr gibt und dann produziert das Ding selber Konflikte mit Altcode. :evil:


1, 4: Application.OnMessage wird doch vor der Verarbeitung (IsPreProcessMessage/IsHintMsg/IsMDIMsg/IsKeyMsg/IsDlgMsg und TranslateMessage/DispatchMessage) ausgeführt. :gruebel:
Also einfach in Application.OnMessage

Delphi-Quellcode:

Handled:=True

und/oder

Delphi-Quellcode:

Msg.message := WM_NULL;

,
aber ein Blick in TApplication.ProcessMessage zeigt, dass nachher dennoch einige Messages verarbeitet werden, selbst wenn Handled=True.

2: Rausfinden was Msg.Wnd ist und dessen WndProc hooken.

3: Du mußt GetMessage/PeekMessage (WH_GETMESSAGE) hooken und nicht DispatchMessage (WH_CALLWNDPROC).

[hoika]

Hallo,

Ja, der Erfinder von TApplicationEvents sollte dafür erschossen werden.
Da erfindet der etwas, damit es keine Konflikte mehr gibt und dann produziert das Ding selber Konflikte mit Altcode.
hm, ist da mein Code gemeint?

1, 4: Application.OnMessage wird doch vor der Verarbeitung (IsPreProcessMessage/IsHintMsg/IsMDIMsg/IsKeyMsg/IsDlgMsg und TranslateMessage/DispatchMessage) ausgeführt.
Also einfach in Application.OnMessage Handled:=True und/oder Msg.message := WM_NULL; ,
aber ein Blick in TApplication.ProcessMessage zeigt, dass nachher dennoch einige Messages verarbeitet werden, selbst wenn Handled=True.
Klappt eben nicht.
Habe ich doch ausprobiert.

2: Rausfinden was Msg.Wnd ist und dessen WndProc hooken.

3: Du mußt GetMessage/PeekMessage (WH_GETMESSAGE) hooken und nicht DispatchMessage (WH_CALLWNDPROC).
Hook nützt ja nichts, ich will, dass die Nachricht "verschwindet", laut MS kann die Nachtricht aber nicht verändert werden. Oder geht das doch???.


Ich habe auf meine Proc und die WndProc (hier z.B. von WPTools) Breakpoints gesetzt,
am Anfang klappt es, aber sobald die WPTools-WndProc aufgerufen wird, kommt meine Proc
nicht mehr zum Zug. Ich müßte also sämtliche Module, wo WndProc überschrieben wird,
selbst anpassen.