Explain errors from GetKeyState / GetCursorPos
The documentation for GetCursorPos
says:
The input desktop must be the current desktop when you call GetCursorPos. Call OpenInputDesktop to determine whether the current desktop is the input desktop. If it is not, call SetThreadDesktop with the HDESK returned by OpenInputDesktop to switch to that desktop.
You can fall foul of this, most commonly when unlocking a workstation. In my code I replace GetCursorPos
with this variant:
function GetCursorPos(var lpPoint: TPoint): BOOL; stdcall;
(* The GetCursorPos API in user32 fails if it is passed a memory address >2GB
which breaks LARGEADDRESSAWARE apps. We counter this by calling GetCursorInfo
instead which does not suffer from the same problem.
In addition we have had problems with GetCursorPos failing when called
immediately after a password protected screensaver or a locked workstation
re-authenticates. This problem initially appeared with XP SP1 and is brought
about because TMouse.GetCursorPos checks the return value of the GetCursorPos
API call and raises an OS exception if the API has failed.
*)
var
CursorInfo: TCursorInfo;
begin
CursorInfo.cbSize := SizeOf(CursorInfo);
Result := GetCursorInfo(CursorInfo);
if Result then begin
lpPoint := CursorInfo.ptScreenPos;
end else begin
lpPoint := Point(0, 0);
end;
end;
You can use your favourite code hooking mechanism to replace GetCursorPos
. I do it like so:
RedirectProcedure(@Windows.GetCursorPos, @CodePatcher.GetCursorPos);
with RedirectProcedure
as described here: Patch routine call in delphi
It turned out for my particular scenario, that GetCursorPos
would fail, but GetCursorInfo
would not fail. But as has been pointed out in the comments, there are scenarios where GetCursorInfo
will also fail. In that case you might find it expedient to arrange that the patched function does not return False
.
As for GetKeyState
, I'm not sure about that one. It's quite possibly similar but GetKeyState
is an API that I am not personally familiar with.