[imojenisys]

Closes #1290.

With the Edit-and-Continue reset prompt open and unanswered, a second keyboard type_text into the code window returned typed 3 key(s). All three keys went into the code under the prompt, to be reverted with it if the prompt was answered No.

• The prompt was shown over the active window, often the running form when a tool typed the key, so the code window stayed usable under it.
• The IDE window's focus manager still reported the code as focused, so the typing's focus check passed.

The reset prompt is now shown over the code editor's own window, as VB6's prompt holds the IDE. IWindowManager.MessageBox takes an optional owner. A minimized or hidden editor window falls back to the active window, as before.

Keyboard type_text and press_key are now refused before a key is sent, ahead of their other checks, while a modal dialog is open over the window they act in (directly or through dialogs between). The refusal names the dialog on top, which takes the keys. The reply's note of open dialogs leaves it out.

What is unchanged:

• A dialog over another window is left to the note, since a person could click past it.
• A dialog that opens during the typing still stops it, as before (type_text's keyboard mode does not stop for a dialog owned by another window, such as the reset prompt over a running form #1257).

A control in a native popup is checked against the window the popup opened from. The type_text and press_key descriptions now say this.

Review

One adversarial reviewer, who read the code and ran probe tests. The live checks weren't run, because the review session had no HexIDE MCP tools. So the prompt's owner in a running IDE, the native popup case and a minimized owner were read from the code, not run.

Finding	Severity	Outcome
With dialogs stacked over the window, the refusal named the one underneath, which can't be answered first	Low–Med	Fixed: names the dialog no other open dialog holds; test
Other IDE dialogs (run-time error, InputBox, About, Font) still open over the active window	Low–Med	Same root cause, outside this change: filed 1297
A control in a native popup (completion list, dropdown) is in a PopupRoot, so the check never ran	Low	Fixed: the popup's window is found through its logical ancestors; headless popups are overlays, so this path isn't run by tests
Descriptions and a code comment were out of date	Low	Fixed
The dialog check ran after the protected-line and typability checks	Low	Fixed: it runs first; test with a read-only box
A minimized owner could hide the prompt	Unverified	Guarded: a minimized editor window isn't used as owner

The reviewer checked that nothing legitimate is refused: typing into a dialog's own box, Enter on a program MsgBox button, and a non-modal owned window. Find is non-modal. Running forms are unowned, so an IDE-owned dialog doesn't block typing into them. There is no deadlock, and the IDE is re-enabled when the prompt closes. WindowManager is the only implementation, and the existing substitutes still match.

Mutation-checked: both refusals, the dialog recorded as named, the topmost pick, and the view's owner each fail a test when removed. WindowManager's own use of the owner can't be reached headlessly, because there's no desktop lifetime. Unit 3086 and integration 1429 pass.

🤖 Generated with Claude Code