WndProc bei Programmen im Hintergrund

[Luckie]

RegisterWindowMessageA('MYSHELLHOOK'); 'MYSHELLHOOK' ist auch nicht so toll. Da gibt es bestimmt einige. Nimm eine GUID und du bist auf der sicheren Seite.

Ich würde noch prüfen, ob RegisterShellHookWindow nicht fehl geschlagen ist.

[UliBru]

Zitat von Luckie:

Nimm eine GUID und du bist auf der sicheren Seite.

Ich würde noch prüfen, ob RegisterShellHookWindow nicht fehl geschlagen ist.

Danke. Mit GUID bin ich einverstanden.

Müsste denn ein optimierter Code nicht in etwa so aussehen?

Delphi-Quellcode:

procedure TMainForm.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  if shellHookWindowRegisteredSuccessfully then
    DeregisterShellHookWindow(Handle);
end;

procedure TMainForm.FormCreate(Sender: TObject);
begin
  ShellHookMessage := RegisterWindowMessageA(myGUID);
  if ShellHookMessage <> 0 then
    shellHookWindowRegisteredSuccessfully := RegisterShellHookWindow(Handle);
  if not shellHookWindowRegisteredSuccessfully then
    MachIrgendeineFehlerbehandlung; 
end;

Ansonsten, wenn RegisterShellHookWindow fehlschlägt, dann findet ja schlichtweg das WndProc mit Message.Msg = ShellHookMessage nicht statt. MachIrgendeineFehlerbehandlung dient dann nur dazu, den Anwender gezielt zu informieren.

Eine generelle Frage, vermutlich einen eigenen Thread wert: man findet x Beispiele, welche die Funktionsergebnisse von API-Aufrufen nicht auswerten. Was ist besser: trotzdem auswerten und das Programm mit Fehlerauswertungen aufblähen oder doch auch ab und zu das Ignorieren von Funktionsergebnissen zulassen? Klar ist, dass das erstere das sicherere Verfahren ist.

[DeddyH]

Zitat von UliBru:

Was ist besser: trotzdem auswerten und das Programm mit Fehlerauswertungen aufblähen oder doch auch ab und zu das Ignorieren von Funktionsergebnissen zulassen?

Es geht ja nicht in erster Linie um Fehlermeldungen, sondern darum, dass man ggf. mit einer Funktionsrückgabe (z.B. einem Handle) weiterarbeitet. Da wäre es doch sinnvoll, erst zu prüfen, ob diese Daten auch gültig sind. Was man im Fehlerfall tut, hängt ja vom Einzelfall ab, evtl. kann man das auch kaltlächelnd ignorieren.

[UliBru]

Das Handle in RegisterShellHookWindow(Handle) ist kein Rückgabewert sondern ein Eingabewert, hier also das Handle des Programms (ich glaube Self.Handle wäre in diesem Fall dasselbe). Der Rückgabewert der API-Funktion ist boolean und zeigt lediglich an, dass die Registrierung erfolgreich war.
Siehe auch http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Der eigentlich verwendete Rückgabewert ist im gegebenen Fall die Variable ShellHookMessage, die in WndProc verwendet wird.

[DeddyH]

Erst kündigst Du eine generelle Frage an, und dann beziehst Du Dich doch auf das spezifische Problem?

[UliBru]

Sorry, hab das mit dem 'Handle' missverstanden und insofern wieder auf die Ausgangsfrage bezogen.

Meine Frage hinsichtlich sorgfältiger Überprüfung von Funktionsergebnissen könnte man insofern auch splitten hinsichtlich
- Rückgabewerte, welche als Ergebniswerte weiterverwendet werden. So z.B. ein zurückgegebenes Handle (Beispiel CreateFileMapping)
- Rückgabewerte, welche anzeigen, dass der Funktionsaufruf ordnungsgemäß ablief oder nicht, also boolean oder Fehlerkonstanten/-listen (mir fällt spontan z.B. TASIOError ein)

Im ersteren Fall wäre eine Fehlerauswertung vermutlich immer sinnvoll, im letzteren scheint dagegen häufiger darauf verzichtet zu werden.

[DeddyH]

Es kommt eben auf den spezifischen Einzelfall an. Wenn ich z.B. mit GetWindowThreadProcessId die ProzessId ermitteln möchte, ist mir die Rückgabe (also die ThreadId) wurscht.