You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 settingWS_CHILD
window style and connecting it to the host window throughSetParent
. This happens despite the host having calledCoAllowSetForegroundWindow
first.Steps to reproduce
RunInSandbox.exe mi TestControl.TestControl
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 firstMoveMouseCursor
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 sendSetCursorPos
events to the high IL parent window also after being attached as a child window.The text was updated successfully, but these errors were encountered: