Wpf 奇怪的键盘焦点事件顺序

奇怪的WPF组合框行为：

我刚刚注意到，在WPF

ComboBox

中，当通过tab键设置键盘焦点（上一个控件的tab焦点）时，

ComboBox

中的

TextBox

（“

PART\u EditableTextBox

”）是PreviewgotKeyboardFocus上隧道事件的源

但出于某种奇怪的原因，如果通过在控件内单击鼠标来接收焦点，则会调用两次

OnPreviewGotKeyboardFocus

：第一次，源是

组合框本身；第二次，源代码也是，
PART\u EditableTextBox

我还注意到，当
组合框
上的设置可聚焦为False时，您仍然可以使用Tab键聚焦，但不能使用鼠标

有人知道为什么会有这种奇怪的行为吗？
来自微软文档

KeyboardNavigation类负责在按下其中一个导航键时实现默认的键盘焦点导航。导航键有：TAB键、SHIFT+TAB键、CTRL+TAB键、CTRL+SHIFT+TAB键、向上箭头键、向下箭头键、向左箭头键和向右箭头键

导航容器的导航行为可以通过以下方式更改：
设置附加的键盘导航属性选项卡Navigation，
ControlTabNavigation和DirectionalNavigation。这些属性是
类型KeyboardNavigationMode，并且可能的值为Continue，
本地、包含、循环、一次和无。默认值为
Continue，这意味着元素不是导航容器

组合框本身是一个导航容器。这意味着当您按tab键时，PART_EditableTextBox的容器在默认情况下将KeyBoardNavigationMode设置为Continue（这意味着焦点直接转到第一个非容器元素）。相反，click事件的工作方式不同，因为您没有按键盘键，所以此行为将被覆盖，并且事件将按WPF在可视树中找到的任何元素的顺序启动。这样做是为了确保在焦点到达文本框之前，可以处理此事件以对控件执行操作。此外，你必须考虑这是必要的，因为WPF无法准确地知道你要点击的内容。这就是为什么他必须按顺序从combobox的每一层引发相同的事件（如果单击扩展器，焦点将不会在PART_EditableTextBox内停止）

简言之，如果您要按TAB键，默认情况下WPF知道最后一个要聚焦的元素是combobox中的文本框，这就是combobox本身不需要它来引发事件的原因。另一方面，如果单击组合框，WPF需要检查最后将聚焦哪个元素，以及在切换焦点之前是否必须执行某些操作

最后，关于Focusable属性，控件的这个属性指示控件是否可以接收焦点，这意味着用户单击控件后，控件可以接收键盘输入。对于设计用于接受用户输入的控件，Focusable通常设置为true。可以接收键盘焦点的部分是文本框。因此，如果在组合框内设置Focusable=false，KeyboardNavigation类将把焦点放在组合框上，而不是文本框上，因为它无法应用其默认行为
感谢您的详细回复。我不得不说，这对我来说仍然没有意义，但至少我现在知道了背后的逻辑。