如何解决 LostFocus/LostKeyboardFocus 问题？

Question

好的，我有一个具有 IsEditing 属性的控件，为了论证，该控件有一个默认模板，该模板通常是文本块，但当 IsEditing 为 true 时，它​​会交换文本框以进行就地编辑。现在，当控件失去焦点时，如果它仍在编辑，则应该退出编辑模式并交换回 TextBlock 模板。很简单，对吧？

想想在 Windows 资源管理器或桌面上重命名文件的行为（这与我所知道的相同......）这就是我们想要的行为。

问题是您无法使用 LostFocus 事件，因为当您切换到另一个窗口（或 FocusManager 元素）时，LostFocus 不会触发，因为控件仍然具有逻辑焦点，因此这不起作用。

如果您改为使用 LostKeyboardFocus，虽然这确实解决了“其他 FocusManager”问题，但现在您有了一个新问题：当您编辑时，右键单击文本框以显示上下文菜单，因为上下文菜单现在有键盘焦点，您的控件将失去键盘焦点，退出编辑模式并关闭上下文菜单，使用户感到困惑！

现在，我尝试在菜单打开之前设置一个标志来忽略 LostKeyboardFocus，然后在 LostKeyboardFocus 事件中使用该标志来确定是否将其踢出编辑模式，但是如果菜单打开并且我单击菜单中的其他位置，应用程序中，由于控件本身不再具有键盘焦点（菜单具有键盘焦点），因此控件永远不会收到另一个 LostKeyboardFocus 事件，因此它仍处于编辑模式。 （我可能需要在菜单关闭时添加一个检查，以查看焦点是什么，然后如果它不是控件，则手动将其踢出 EditMode。这看起来很有希望。）

所以...任何人都知道我如何成功地编写此行为？

标记

Answer 1

好吧...这很“有趣”，就像程序员的乐趣一样。弄清楚这个问题真的很痛苦，但我脸上挂着灿烂的笑容。 （考虑到我自己拍得很用力，是时候给我的肩膀买一些 IcyHot 了！:P）

无论如何，这是一个多步骤的事情，但一旦你弄清楚了一切，就会出人意料地简单。简而言之，您需要使用两者 LostFocus 和 LostKeyboardFocus，而不是其中之一。

LostFocus 很简单。每当您收到该事件时，请将 IsEditing 设置为 false。完成了，完成了。

上下文菜单和失去键盘焦点

LostKeyboardFocus 有点棘手，因为控件的上下文菜单可以在控件本身上触发它（即当控件的上下文菜单打开时） ，控件仍然具有焦点，但失去了键盘焦点，因此 LostKeyboardFocus 触发。）

要处理此行为，您可以重写 ContextMenuOpening （或处理该事件）并设置一个类-level 标志指示菜单正在打开。 （我使用 bool _ContextMenuIsOpening。）然后在 LostKeyboardFocus 覆盖（或事件）中，检查该标志，如果已设置，则只需清除它即可，不执行任何其他操作。但是，如果未设置，则意味着除了打开上下文菜单之外，还有其他原因导致控件失去键盘焦点，因此在这种情况下，您确实需要将 IsEditing 设置为 false。

已打开的上下文菜单

现在，如果某个控件的上下文菜单已打开，并且因此该控件已经失去键盘焦点（如上所述），并且之前单击应用程序中的其他位置，则会出现奇怪的行为新控件获得焦点，您的控件首先获得键盘焦点，但只持续一瞬间，然后它立即将其交给新控件。

这实际上对我们有利，因为这意味着我们还将获得另一个 LostKeyboardFocus 事件，但这次 _ContextMenuOpening 标志将设置为 false，就像上面描述的那样，我们的 LostKeyboardFocus然后，code> 处理程序会将 IsEditing 设置为 false，这正是我们想要的。我喜欢机缘巧合！

现在，如果焦点只是转移到您单击的控件上，而不首先将焦点设置回拥有上下文菜单的控件，那么我们必须执行一些操作，例如挂钩 ContextMenuClosing 事件并检查什么控件接下来将获得焦点，那么如果即将获得焦点的控件不是生成上下文菜单的控件，我们只需将 IsEditing 设置为 false，这样我们基本上就躲过了一劫那里。

警告：默认上下文菜单

现在还有一个警告，如果您使用文本框之类的东西并且没有在其上明确设置您自己的上下文菜单，那么您不 得到ContextMenuOpening事件，这让我很惊讶。不过，这很容易解决，只需使用与默认上下文菜单相同的标准命令（例如剪切、复制、粘贴等）创建一个新的上下文菜单并将其分配给文本框即可。它看起来完全一样，但现在您得到了设置标志所需的事件。

但是，即使您遇到问题，就像您正在创建第三方可重用控件并且该控件的用户想要拥有自己的上下文菜单一样，您也可能会意外地将自己的优先级设置为更高，并且会覆盖他们的优先级！

解决方法是，由于文本框实际上是我的控件的 IsEditing 模板中的一个项目，我只需在外部控件上添加一个名为 IsEditingContextMenu 的新 DP，然后将其绑定通过内部 TextBox 样式添加到文本框，然后我在该样式中添加了一个 DataTrigger 来检查外部控件上的 IsEditingContextMenu 的值，如果它为空，我设置了上面刚刚创建的默认菜单，该菜单存储在资源中。

这是文本框的内部样式（名为“Root”的元素表示用户实际在其 XAML 中插入的外部控件）...

<Style x:Key="InlineTextbox" TargetType="TextBox">

    <Setter Property="OverridesDefaultStyle" Value="True"/>
    <Setter Property="FocusVisualStyle"      Value="{x:Null}" />
    <Setter Property="ContextMenu"           Value="{Binding IsEditingContextMenu, ElementName=Root}" />

    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="{x:Type TextBoxBase}">

                <Border Background="White" BorderBrush="LightGray" BorderThickness="1" CornerRadius="1">
                    <ScrollViewer x:Name="PART_ContentHost" />
                </Border>

            </ControlTemplate>
        </Setter.Value>
    </Setter>

    <Style.Triggers>
        <DataTrigger Binding="{Binding IsEditingContextMenu, RelativeSource={RelativeSource AncestorType=local:EditableTextBlock}}" Value="{x:Null}">
            <Setter Property="ContextMenu">
                <Setter.Value>
                    <ContextMenu>
                        <MenuItem Command="ApplicationCommands.Cut" />
                        <MenuItem Command="ApplicationCommands.Copy" />
                        <MenuItem Command="ApplicationCommands.Paste" />
                    </ContextMenu>
                </Setter.Value>
            </Setter>
        </DataTrigger>
    </Style.Triggers>

</Style>

请注意，您必须在样式中设置初始上下文菜单绑定，而不是直接在文本框中设置否则，样式的 DataTrigger 会被直接设置的值取代，从而导致触发器无用，并且如果用户在上下文菜单中使用“null”，您就会回到第一个方块。 （如果您想隐藏菜单，无论如何都不会使用“null”。您可以将其设置为空菜单，因为 null 表示“使用默认值”）

因此现在用户可以使用常规的 ContextMenu< /code> 属性，当 IsEditing 为 false 时...他们可以在 IsEditing 为 true 时使用 IsEditingContextMenu，并且如果他们没有指定 IsEditingContextMenu >，我们定义的内部默认值用于文本框。由于文本框的上下文菜单实际上永远不会为空，因此它的 ContextMenuOpening 始终会触发，因此支持此行为的逻辑有效。

就像我说的……弄清楚这一切确实很痛苦，但如果我在这里没有一种非常酷的成就感，那该死的。

我希望这可以帮助其他遇到同样问题的人。欢迎在这里回复或者私信我提问。

标记

Answer 2

不幸的是，您正在寻找一个复杂问题的简单解决方案。简单地说，问题在于拥有智能自动提交用户界面控件，这些控件需要最少的交互，并且当您“切换离开”它们时“做正确的事情”。

它之所以复杂是因为什么是正确的取决于应用程序的上下文。 WPF 采取的方法是为您提供逻辑焦点和键盘焦点概念，并让您决定如何根据您的情况做正确的事情。

如果打开上下文菜单怎么办？如果打开应用程序菜单会发生什么？如果焦点切换到另一个应用程序怎么办？如果打开属于本地控件的弹出窗口怎么办？如果用户按 Enter 键关闭对话框怎么办？所有这些情况都可以处理，但如果您有提交按钮或用户必须按 Enter 才能提交，那么它们都会消失。

所以你有三个选择：

• 让控件在具有逻辑焦点时保持编辑状态
• 添加显式提交或应用机制
• 处理当你尝试支持自动提交时出现的所有混乱情况

Answer 3

我不确定上下文菜单问题，但我试图做类似的事情，发现使用鼠标捕获可以为您提供（大约）您所追求的行为：

请参阅此处的答案：控件如何处理外部的鼠标单击那个控件？

Answer 4

难道不是更容易：

    void txtBox_LostKeyboardFocus(object sender, KeyboardFocusChangedEventArgs e)
    {
        TextBox txtBox = (sender as TextBox);

        if (e.NewFocus is ContextMenu && (e.NewFocus as ContextMenu).PlacementTarget == txtBox)
        {
            return;
        }

        // Rest of code for existing edit mode here...
    }

Answer 5

不确定，但这可能会有所帮助。我对可编辑组合框也有类似的问题。我的问题是我正在使用 OnLostFocus 重写方法，但该方法没有被调用。修复的是我已将回调附加到 LostFocus 事件，并且一切正常。

Answer 6

我在这里寻找类似问题的解决方案：我有一个 ListBox，当 ContextMenu 打开时它会失去焦点，我不希望这种情况发生。

我的简单解决方案是将 Focusable 设置为 False，对于 ContextMenu 及其 MenuItem ：

<ContextMenu x:Key="QueryResultsMenu" Focusable="False">
    <ContextMenu.Resources>
        <Style TargetType="MenuItem">
            <Setter Property="Focusable" Value="False"/>
        </Style>
    </ContextMenu.Resources>
    <MenuItem ... />
</ContextMenu>

希望这会有所帮助未来的探索者...