-
Notifications
You must be signed in to change notification settings - Fork 12
Description
Observed problem: SetCursorPos calls fail in a medium IL COM/OLE control when running as child window within an elevated (high IL) host process.
The reason for this failure seem to be that UIPI silently blocks SetForegroundWindow calls in the medium IL COM/OLE control after setting WS_CHILD window style and connecting it to the host window through SetParent. This happens despite the host having called CoAllowSetForegroundWindow first.
Steps to reproduce
- From a command prompt started with "Run as Admin":
RunInSandbox.exe mi TestControl.TestControl - Observe the following error:
Moving mouse cursor to top-left corner...
[FAILED] Access is denied.
This problem does not occur if running RunInSandbox.exe mi TestControl.TestControl from a non-elevated command prompt.
Code tweaks to make it work
Applying any one of the changes below will make the problem go away:
1, Stop setting the WS_CHILD window style.
2. Stop calling SetParent(child_wnd, wnd).
3. Run SetCursorPos from a non-main thread in the COM/OLE process (change the first MoveMouseCursor argument to true).
Tweak 1. and 2. does not seem attractive, since they would undermine the child window UI integration. Tweak 3. is furthermore not attractive, since it would require invasive changes to the COM/OLE control to make it "parent IL aware".
I'm therefore seeking a non-invasive way of "granting" the COM/OLE control permission to SetForegroundWindow or being allowed to send SetCursorPos events to the high IL parent window also after being attached as a child window.
