奇怪的WPF ComboBox行为：
我刚注意到在WPF ComboBox中，通过tab键设置了键盘焦点（从前一个控件中选择了焦点），TextBox内的ComboBox（＆ ＃34; PART_EditableTextBox＆＃34;）是隧道事件OnPreviewGotKeyboardFocus的来源。
但是由于一些奇怪的原因，如果通过单击控件内的鼠标来接收焦点，则OnPreviewGotKeyboardFocus会被调用两次：第一次，Source是ComboBox本身;第二次，来源又是PART_EditableTextBox。
我还注意到，当ComboBox上的设置可聚焦为假时，您仍然可以使用Tab键将焦点对准它，但不能使用鼠标。
有谁知道为什么会出现这种奇怪的行为？
答案 0 :(得分：1)
来自Microsoft doc。
当按下其中一个导航键时，KeyboardNavigation类负责实现默认键盘焦点导航。导航键为：TAB，SHIFT + TAB，CTRL + TAB，CTRL + SHIFT + TAB，UPARROW，DOWNARROW，LEFTARROW和RIGHTARROW键。
导航容器的导航行为可以通过更改 设置附加的KeyboardNavigation属性TabNavigation， ControlTabNavigation和DirectionalNavigation。这些属性是 KeyboardNavigationMode类型和可能的值是继续， 本地，包含，循环，一次和无。默认值为 继续，这意味着该元素不是导航容器。
组合框本身就是一个导航容器。这意味着当您按Tab键时，PART_EditableTextBox的容器默认情况下将KeyBoardNavigationMode设置为Continue（这意味着焦点直接转到第一个非容器元素）。然后，click事件会不同地工作，因为您没有按下键盘键，此行为被覆盖，并且事件由WPF将在可视树中找到的任何元素按顺序启动。这样做是为了确保您可以在焦点到达文本框之前处理此事件以对您的控件执行操作。此外，您必须考虑这是必要的，因为WPF无法准确知道您要单击的内容。这就是为什么他必须按顺序从组合框的每一层中引发相同的事件（如果你单击扩展器，焦点将不会在PART_EditableTextBox内停止）。
简而言之，如果您要按TAB，默认情况下WPF会知道将要聚焦的最后一个元素是组合框内的文本框，这就是组合框本身不需要它来引发事件的原因。另一方面，如果你单击组合框，WPF需要检查最后会聚焦哪个元素，以及在切换焦点之前是否有必须完成的操作。
最后关于Focusable属性，控件的这个属性指示控件是否可以获得焦点，这意味着控件可以在用户单击控件后接收键盘输入。对于旨在接受用户输入的控件，Focusable通常设置为true。可以接收键盘焦点的部分是文本框。因此，如果在组合框内设置Focusable = false，则KeyboardNavigation类会将焦点放在Combobox而不是Textbox上，因为它无法应用它的默认行为