我已经阅读了关于key bindings的明确教程几次，但我的大脑缓存似乎不够大，无法容纳复杂的过程。

我正在调试一个键绑定(bind)问题(原来我使用了错误的 JComponent.WHEN_* 条件)，我偶然发现了一个关于包 private javax.swing.KeyboardManager 的简明而有趣的 javadoc由一位(不幸的)匿名 Java 工程师编写。

我的问题是:除了在一开始检查的 KeyEventDispatcher 之外，描述是否遗漏和/或错误了什么？

The KeyboardManager class is used to help dispatch keyboard actions for the WHEN_IN_FOCUSED_WINDOW style actions. Actions with other conditions are handled directly in JComponent.

Here's a description of the symantics [sic] of how keyboard dispatching should work atleast [sic] as I understand it.

KeyEvents are dispatched to the focused component. The focus manager gets first crack at processing this event. If the focus manager doesn't want it, then the JComponent calls super.processKeyEvent() this allows listeners a chance to process the event.

If none of the listeners "consumes" the event then the keybindings get a shot. This is where things start to get interesting. First, KeyStokes [sic] defined with the WHEN_FOCUSED condition get a chance. If none of these want the event, then the component walks though it's [sic] parents looked for actions of type WHEN_ANCESTOR_OF_FOCUSED_COMPONENT.

If no one has taken it yet, then it winds up here. We then look for components registered for WHEN_IN_FOCUSED_WINDOW events and fire to them. Note that if none of those are found then we pass the event to the menubars and let them have a crack at it. They're handled differently.

Lastly, we check if we're looking at an internal frame. If we are and no one wanted the event then we move up to the InternalFrame's creator and see if anyone wants the event (and so on and so on).

(更新)如果您对键绑定(bind)指南中的这个粗体警告感到疑惑:

Because the order of searching the components is unpredictable, avoid duplicate WHEN_IN_FOCUSED_WINDOW bindings!

这是因为 KeyboardManager#fireKeyboardAction 中的这个段:

     Object tmp = keyMap.get(ks);
     if (tmp == null) {
       // don't do anything
     } else if ( tmp instanceof JComponent) {
           ...
     } else if ( tmp instanceof Vector) { //more than one comp registered for this
         Vector v = (Vector)tmp;
             // There is no well defined order for WHEN_IN_FOCUSED_WINDOW
             // bindings, but we give precedence to those bindings just
             // added. This is done so that JMenus WHEN_IN_FOCUSED_WINDOW
             // bindings are accessed before those of the JRootPane (they
             // both have a WHEN_IN_FOCUSED_WINDOW binding for enter).
             for (int counter = v.size() - 1; counter >= 0; counter--) {
         JComponent c = (JComponent)v.elementAt(counter);
         //System.out.println("Trying collision: " + c + " vector = "+ v.size());
         if ( c.isShowing() && c.isEnabled() ) { // don't want to give these out
             fireBinding(c, ks, e, pressed);
         if (e.isConsumed())
             return true;
         }
     }

所以搜索的顺序实际上是可预测的，但显然取决于这个特定的实现，所以最好不要完全依赖它。让它不可预测。

(Javadoc 和代码来自 WinXP 上的 jdk1.6.0_b105。)

最佳答案

我们需要从Component.dispatchEventImpl开始调试.
只需通读该方法的源代码注释，您就可以完美了解事件在 Swing 中的流动方式(您也可以从 EventQueue.pumpEventsForHeirarchy 开始上一级)。

为了清楚起见，让我摘录一段代码:

1. 设置当前事件的时间戳和修饰符。;预调度员。在我们通知 AWTEventListeners 之前，请在此处进行任何必要的重定向/重新排序。
2. 允许 Toolkit 将此事件传递给 AWTEventListeners。
3. 如果没有人使用某个键事件，则允许 KeyboardFocusManager 处理它。
4. 允许输入法处理事件
5. 在交付前预先处​​理任何特殊事件
6. 交付事件以进行正常处理
7. 4061116 的特殊处理:浏览器关闭模态对话框的钩子(Hook)。:)
8. 允许对等方处理事件。除了 KeyEvents，它们将在所有 KeyEventPostProcessors 之后由对等方处理(参见 DefaultKeyboardFocusManager.dispatchKeyEvent())

现在您可以将上述流程与您的描述进行匹配，判断其是否正确。但重点是您真的不应该依赖私有(private)类的 javadoc，原因是开发人员通常不关心在代码更改时更新私有(private)类的注释，因此文档可能会过时。

关于java - Java 如何调度 KeyEvents？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3929932/