flaui-cross-process-input

Diagnoses and fixes FlaUI mouse and keyboard input failures in WPF UI automation tests.

Updated Nov 22, 2023
One-click install
npx skills add https://github.com/parksanghoon-sys/TestCode --skill flaui-cross-process-input-parksanghoon-sys
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: flaui-cross-process-input
Source: https://github.com/parksanghoon-sys/TestCode/tree/main/src/Modbus/wpf-dev-pack/.agents/skills/flaui-cross-process-input
Command: npx skills add https://github.com/parksanghoon-sys/TestCode --skill flaui-cross-process-input-parksanghoon-sys

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? FlaUI tests that drive WPF applications from a separate process often fail silently: Mouse.Down does nothing, drag-and-drop is ignored, clicks hit the wrong element, or tests pass individually but fail when run together. This Skill identifies the root causes — stuck keys, SetCursorPos hit-test gaps, xUnit parallel execution, and incorrect canvas coordinates — and provides concrete fixes. ## Core Features & Use Cases - Stuck-key diagnosis and release: Detect keys left pressed by Keyboard.Press and release them with ReleaseAllKeys or ReleaseModifierKeys before mouse gestures. - SendInput-based mouse injection: Replace SetCursorPos with SendInput MOVE/ABSOLUTE events so WPF hit tests update correctly, including atomic move-and-click sequences. - Drag interpolation tuning: Fix adorner flickering during drags by adjusting step counts, sleep intervals, and routing paths around interactive zones. - xUnit parallelization control: Configure xunit.runner.json to disable parallel execution so tests do not fight over shared mouse and keyboard state. - Use Case: A FlaUI xUnit test drags a connector in a Nodify-based WPF editor but the gesture is silently rejected; this Skill walks through the diagnostic checklist, identifies a stuck DELETE key from Keyboard.Press, and fixes it by switching to Keyboard.Type plus ReleaseModifierKeys. ## Quick Start Ask the assistant to diagnose why your FlaUI Mouse.Down or drag gesture is silently failing on a WPF control and apply the appropriate fix.

Frequently Asked Questions about flaui-cross-process-input

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Why does FlaUI Mouse.Down have no effect on my WPF control?▼

FlaUI Mouse.Down fails silently when a key is stuck in the pressed state, because WPF controls checking Keyboard.IsKeyDown reject the gesture. Release stuck keys with keybd_event key-up calls and add a 200ms delay before the mouse interaction.

How do I fix FlaUI drag-and-drop that is silently ignored?▼

Replace Mouse.MoveTo with SendInput using MOUSEEVENTF_MOVE and MOUSEEVENTF_ABSOLUTE so WPF receives WM_MOUSEMOVE and updates its hit test. Use 3-5 interpolated move steps with 50ms sleeps between them for reliable drag recognition.

What is the difference between FlaUI Keyboard.Press and Keyboard.Type?▼

Keyboard.Press sends only key-down, leaving the key pressed in the OS input state, while Keyboard.Type sends key-down plus key-up. Use Keyboard.Type for single keystrokes to avoid stuck keys breaking subsequent mouse gestures.

Why do FlaUI xUnit tests fail randomly when run together?▼

Parallel test execution causes tests to fight over the shared mouse, keyboard, and window focus. Add an xunit.runner.json with parallelizeAssembly and parallelizeTestCollections set to false, and copy it to the output directory.

Why does my FlaUI click hit the wrong WPF element?▼

FlaUI Mouse.MoveTo uses SetCursorPos, which moves the cursor without injecting WM_MOUSEMOVE, so WPF never updates its hit test. Use SendInput with absolute move flags, and calculate canvas positions from node UIA BoundingRectangle values rather than editor bounds.