Schließen eines fremden Programms verhindern

[Boombuler]

Ich hätte auch nicht die Message verändert sondern einfach Result := 0 beim Abbrechen. (Toll nu fehlt mir das Verb!)
So kannst du die HookChain unterbrechen und der Calc bekommt gar keine Msg mehr!

Greetz
Boombuler

[TStringlist]

nee, nur alleine mit einem "Result:=0" (plus jeweils einem exit dahinter ..dann in der Case-Anweisung) geht's nicht. Man könnte es höchstens noch zusätzlich machen, ungefähr so wie ich das ja auch "Gestern um 18:23" beim beabsichtigten WM_Quit-Abfangen versuchte.

[PMM]

Hallo TStringlist,
ich hab mal versucht das nachzuvollziehen, bekomme es aber nicht hin. Bei mir wird nur das X der Titelzeile blockiert (auch das nicht ganz zuverlässig). Welchen WH_xxx Typ verwendest du bei SetWindowsHookEx?
PMM

[TStringlist]

Hi PMM, gemäß des PSDKs ist "GetMsgProc" die offizielle Placeholderbezeichnung für die Application-defined HookProc eines WH_GETMESSAGE-Hooks.

edit: ...außerdem, wegen der nicht ganz zuverlässig blockierbaren X-Button nehme ich an, wirst du dann als OS das Windows-XP benutzen (da sind diese Tasten wohl etwas anders dimensioniert als beim W2k). In diesem Falle müsstest du diese Korrekturwerte nämlich entsprechend anpassen ...jene welche mit denen ich vom ProgRect auf das X-Button-Rect zurückrechne. Das Beste wäre allerdings diese Korrekturwerte für beide OS zu wissen und die dann, je nachdem auf welchem OS das Prog gerade läuft, dann auch noch zusätzlich über die Parameterliste der SetHook-Funktion zur eigentlichen HookProc mit durchzuschleusen.

[PMM]

Txs TStringList,
WH_GETMESSAGE hatte ich geahnt und funktioniert auch für WM_NCLButtonDown, die Korrekturen für WIN2K werde ich schon rausfinden (andere brauch ich hier nicht
Das Problem ist, dass weder WM_CLOSE noch WM_SysCommand jemals erreicht werden
PMM

[TStringlist]

Ein nicht ganz korrekt berechnetes X-Button-Rect könnte übrigens auch darauf zurück gehen, dass das Programm (bei dem du das Schließen so verhindern willst) mit BorderStyle=bsNone erzeugt wurde. Denn dann wären eventuelle BorderIcons (also auch die X-Button) natürlich Individual-Anfertigungen und diese Korrektur-Werte zur Errechnung des X-Button-Rect müssten demzufolge auch immer entsprechend extra angepasst werden. Die im obigen Beispiel diesbezüglich benutzen Werte passen jedenfalls für BorderStyle=bsNormal-Programme und solche von der Sorte Notepads etc..

Und da wir gerade bei Notepad sind... Wenn ich das z.B. übers MainMenue (Datei -> Beenden) beenden möchte, dann ist jedenfalls auch ein Abfangen einer WM_Close-Message nötig. Welche Message da aber letztlich immer abgefangen werden muss, hängt dann aber wohl auch vom Programm selbst ab. Je nach dem, wie es den Programmabbruch eben für sich selbst verursacht. So muss z.B. bei einem Delphi-Prog, das über die close-Methode beendet wird, kein WM_Close abgefangen werden, sondern wider Erwarten ein WM_Quit.

Warum bei dir keine WM_SysCommand-Message (mit wParam = SC_CLOSE) in der HookProc vorbeikommt kann ich mir allerdings nicht so recht erklären. Die müsste beim Prog-Abbruch übers WindowMenue (also dasjenige, welches beim Rechtsclick auf die Programm-Button in der Taskbar aufpopt !) da eigentlich schon auftauchen.

[dizzy]

Bei einer Form mit bsNone entfällt der Non-Client-Bereich, weshalb es nie zu einer WM_NCL* Message kommen wird . (Zumindest dann nicht, wenn es nicht explizit reimplementiert wurde... wenn das überhaupt geht.)

Dass heisst dass ein solcher Fake-X-Button sehr wahrscheinlich (aber auch nur wahrscheinlich) ein WM_Close auslösen wird. Damit entfällt ein mühsähliges Anpassen des Kollisionsbereiches .

\\edit: Mit XP-Styles hat man mit deiner Methode im Übrigen ganz verloren, da der Button dort völlig beliebig im NC-Bereich verteilt werden kann. Du müsstest JEDES existierende Style kennen und separat implementieren. So sehr allgemein ist dein Ansatz daher leider nicht - wobei ich aber zugeben muss, dass ich mangels Erfahrung in diesem Bereich, keinen besseren Lösungsvorschlag anbieten kann 8).

[TStringlist]

Zitat von dizzy:

Bei einer Form mit bsNone entfällt der Non-Client-Bereich, weshalb es nie zu einer WM_NCL* Message kommen wird .

jo, lustig aber wahr,...

...da hat mich wohl einfach nur der missionarische Eifer etwas zu sehr gepackt und irgendwohin davongetragen ...

Übrigens ist es wahr, bei Delphi-Progs, die über die close-Methode abbrechen (wie wahrscheinlich immer bei dann Fake-X-Buttons), ist ein WM_Quit abzufangen.

Außerdem sollte die Lösung ja auch sowieso nur eine sein, mittels der ein spezielles, schon bekanntes anderes Programm entsprechend präpariert werden kann. Und für irgendein solches, eben schon existierendes, anderes Programm ist es nach einer kleinen Anpassung immer noch eine brauchbare Methode, imo. Programme die sowas über einen globalen Hook bei gleich allen anderen (sonst eher unbekannten) Progs verursachen würden, gehörten dann ja wahrscheinlich auch ohnehin mehr in die Spalte "Scherzartikel".