Ctrl+F in message text box no longer hijacked by TreeView filter (#873)

[RaoulJacobs]

Summary

Fixes #873 — Ctrl+F pressed while the message body (FastColoredTextBox) has focus no longer redirects to the TreeView filter box.

Root cause

ProcessCmdKey in MainForm intercepted Ctrl+F unconditionally, including when a FastColoredTextBox (message text, deadletter text) had focus.

Fix

Added a GetFocusedControl helper that walks the ContainerControl hierarchy to find the actual focused control. If it is a FastColoredTextBox, the key event is passed through to the control's native handler.

protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
    if (keyData == (Keys.Control | Keys.F))
    {
        if (GetFocusedControl(this) is FastColoredTextBoxNS.FastColoredTextBox)
            return base.ProcessCmdKey(ref msg, keyData);

        filterTreeViewTextBox.Focus();
        filterTreeViewTextBox.SelectAll();
        return true;
    }
    return base.ProcessCmdKey(ref msg, keyData);
}

private static Control GetFocusedControl(Control control)
{
    if (control is ContainerControl cc && cc.ActiveControl != null)
        return GetFocusedControl(cc.ActiveControl);
    return control;
}

Test plan

• Ctrl+F with Message Text box focused → stays in text box (native find)
• Ctrl+F with Deadletter Text box focused → stays in text box
• Ctrl+F with focus elsewhere (tree, properties grid) → focuses TreeView filter box

[ErikMogensen]

Thank you @RaoulJacobs !

@claude, please check this pr

[claude]

Claude finished @ErikMogensen's task in 3m 30s —— View job

---

PR Review

• Read changed files and gather context
• Review code for correctness, bugs, and best practices
• Post review findings

---

Summary

This is a clean, minimal fix for a genuine UX issue. The approach is correct and well-structured.

---

What the change does

ProcessCmdKey in MainForm intercepted Ctrl+F unconditionally — even when a FastColoredTextBox (message body, deadletter, etc.) had focus — redirecting keystrokes to the TreeView filter box. The fix adds a recursive helper that walks the ContainerControl hierarchy to find the actual focused leaf control, and bails out early if it's a FastColoredTextBox, allowing that control's native find dialog to open instead.

---

Positive aspects

• Targeted: Only 11 lines added, no collateral changes.
• Correct pattern: The ContainerControl.ActiveControl recursion is the standard WinForms technique for finding the truly-focused control within a nested hierarchy. Each ContainerControl (Form, UserControl, SplitContainer) tracks its active child, so the recursion correctly drills through the UI tree.
• private static is appropriate: No instance state captured; good practice.
• Existing behavior preserved: Non-FastColoredTextBox controls still redirect Ctrl+F to the filter box as before.
• Test plan is thorough: Covers message text, deadletter text, and "focus elsewhere" cases.

---

Minor suggestions

1. Consider adding a using FastColoredTextBoxNS; directive (not a blocker)

MainForm.cs has no using FastColoredTextBoxNS; import, so the full namespace qualifier is used inline:

// src/ServiceBusExplorer/Forms/MainForm.cs:7751
if (GetFocusedControl(this) is FastColoredTextBoxNS.FastColoredTextBox)

Other files that reference this type (MessageForm.cs, TabControlHelper.cs) add a using at the top. Adding one here would make the is-pattern read as is FastColoredTextBox, consistent with the rest of the project. That said, the full qualification is unambiguous and works fine as-is. Fix this →

2. Recursion terminates at non-ContainerControl containers (informational only)

Panel, GroupBox, and TabPage do not inherit from ContainerControl, so the recursion stops if one of these sits between two ContainerControls in the focus chain. In this app's layout (Form → SplitContainer → panels → TabControl/TabPage → UserControl → FastColoredTextBox), the SplitContainers and UserControls are ContainerControls and track ActiveControl, so the recursion does reach the text box in practice.

If ever a future layout change introduced a plain Panel between two ContainerControls in a path leading to FastColoredTextBox, the behaviour would silently fall back to the old (redirect-to-filter) behaviour rather than breaking. A fully reliable alternative would be the Win32 GetFocus() API:

// No recursion needed; directly asks Windows which HWND has focus
[System.Runtime.InteropServices.DllImport("user32.dll")]
private static extern IntPtr GetFocus();

private static Control GetFocusedControl() =>
    Control.FromHandle(GetFocus());

But NativeMethods.SendMessage is already used in this file, so a P/Invoke isn't out of place. This is a minor robustness note for an already-functional fix, not a required change.

---

Verdict

Looks good to merge. The fix is correct for the app's current UI structure, well-scoped, and the test plan covers the meaningful cases. The suggestions above are cosmetic/informational.

[ErikMogensen]

Thanks!