Type Alias MaaWin32InputMethod 

pub type MaaWin32InputMethod = u64;

@brief Win32 input method

No bitwise OR, select ONE method only.

No default value. Client should choose one as default.

Different applications process input differently, there is no universal solution.

Method	Compatibility	Require Admin	Seize Mouse	Background Support	Notes
Seize	High	No	Yes	No
Medium	Maybe	No	Yes
PostMessage	Medium	Maybe	No	Yes
No	Yes	No			PostThreadMessage
Low	Maybe	No	Yes	Deprecated
SendMessageWithCursorPos	Medium	Maybe	Briefly	Yes	Moves cursor to target position, then
restores		PostMessageWithCursorPos	Medium	Maybe	Briefly
to target position, then restores		SendMessageWithWindowPos	Medium	Maybe	No
Moves window to align target with cursor, then restores		PostMessageWithWindowPos	Medium	Maybe	No
Moves window to align target with cursor, then restores		Interception	Medium	Yes	No
Driver-level input injection via the Interception driver		AnchoredTouch	Medium	Maybe	No
Yes	Injects synthetic touch points, never moves the cursor

Note:

• Admin rights mainly depend on the target application’s privilege level. If the target runs as admin, MaaFramework should also run as admin for compatibility.
• “WithCursorPos” methods briefly move the cursor to target position, send message, then restore cursor position. This “briefly” seizes the mouse but won’t block user operations.
• “WithWindowPos” methods briefly move the window so the target aligns with the current cursor position, send message, then restore the window position. The cursor is not moved.
• “AnchoredTouch” injects synthetic touch points, the target window receives WM_POINTER messages. The cursor is never moved and the foreground window is never changed. Since synthetic pointers are dispatched by desktop Z-order, the target window is briefly raised to topmost while the target point is occluded, and restored once all contacts are released. If raising does not take effect, the operation fails instead of injecting into the window that occludes the target. Raising requires WS_EX_LAYERED on the target window, which is added on the first raise, verified before every raise, and removed when the controller goes idle unless another module is relying on that layered state by then. If the style cannot be kept or the opacity cannot be lowered, the operation fails rather than raising the target window visibly. Windows layered via UpdateLayeredWindow are not supported. CS_OWNDC / CS_CLASSDC window classes are documented as incompatible with WS_EX_LAYERED, but that restriction does not always hold in practice, so such classes only produce a warning and the actual API results decide. A minimized target window is not supported and the operation fails, since its client area is off-screen and raising does not change that. Screencap methods with pseudo-minimize take the window out of that state before every capture, so this does not occur with them. WS_EX_TRANSPARENT is temporarily removed while the window is borrowed, since it lets input pass through to the windows underneath. Because the screencap side writes the same window state, the borrowed attributes are verified before being restored, and left alone once taken over. Clicking and swiping only. Keyboard can be routed to another method, but scroll cannot: it always goes through the mouse method and a synthetic touch device has no wheel.