blocks|key|1832325|text|首先要了解的是JavaFX如何调度事件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1832326|当一个Event被触发时，它有一个相关的EventTarget。如果目标在场景图中，则Event的路径从Window开始，沿场景图向下，直到到达EventTarget。然后，Event返回场景图，直到它再次到达Window。这分别称为“捕获阶段”和“冒泡阶段”。在捕获阶段调用事件过滤器，在冒泡阶段调用事件处理程序。使用onXXX属性(例如onMouseClicked)设置的EventHandler是特殊类型的处理程序(即不是过滤器)。|offset|length|style|CODE|1832327|EventDispatcher接口具有以下方法：|1832328|public+Event+dispatchEvent(Event+event,+EventDispatChain+tail)+{+...+}|code-block|syntax|javascript|1832329|在这里，event是被分派的Event，tail是由EventTarget.buildEventDispatchChain(EventDispatchChain)递归构建的EventDispatchChain。如果在方法的执行过程中使用了event，这将返回null。|1832330|EventDispatchChain是一堆EventDispatcher，每次你调用tail.dispatchEvent(event)，你实际上是从顶部弹出一个EventDispatcher并调用它。|1832331|@Override
public+Event+dispatchEvent(Event+event,+EventDispatchChain+tail)+{
++++//+First,+dispatch+event+for+the+capturing+phase
++++event+=+dispatchCapturingEvent(event);

++++if+(event.isConsumed())+{
++++++++//+One+of+the+EventHandlers+invoked+in+dispatchCapturingEvent
++++++++//+consumed+the+event.+Return+null+to+indicate+processing+is+complete
++++++++return+null;
++++}

++++//+Forward+the+event+to+the+next+EventDispatcher+in+the+chain
++++//+(i.e.+on+the+stack).+This+will+start+the+"capturing"+on+the
++++//+next+EventDispatcher.+Returns+null+if+event+was+consumed+down
++++//+the+chain
++++event+=+tail.dispatchEvent(event);

++++//+once+we've+reached+this+point+the+capturing+phase+has+completed

++++if+(event+!=+null)+{
++++++++//+Not+consumed+from+down+the+chain+so+we+now+handle+the
++++++++//+bubbling+phase+of+the+process
++++++++event+=+dispatchBubblingEvent(event);

++++++++if+(event.isConsumed())+{
++++++++++++//+One+of+the+EventHandlers+invoked+in+dispatchBubblingEvent
++++++++++++//+consumed+the+event.+Return+null+to+indicate+processing+is+complete
++++++++++++return+null;
++++++++}
++++}

++++//+return+the+event,+or+null+if+tail.dispatchEvent+returned+null
++++return+event;
}|1832332|您可能想知道dispatchCapturingEvent和dispatchBubblingEvent是在哪里定义的。这些方法将由您创建，并将调用适当的EventHandler。您可能还想知道为什么这些方法返回Event。原因很简单:在处理Event的过程中，这些方法以及tail.dispatchEvent可能会更改Event。但是，除了consume()之外，Event及其子类基本上是不可变的。这意味着任何其他更改都需要创建一个新的Event。事件处理流程的其余部分应该使用这个新的Event。|1832333|对tail.dispatchEvent的调用实际上总是返回Event的一个新实例。这是因为EventDispatchChain中的每个EventDispatcher通常与其自己的源(例如，Label或Window)相关联。当调用EventHandler时，Event的源必须与EventHandler注册到的Object相同；如果EventHandler已注册到Window，则event.getSource()必须在所述Window执行期间返回该EventHandler。实现此目的的方法是使用<代码>D50方法。|1832334|Event+oldEvent+=+...;
Event+newEvent+=+oldEvent.copyFor(newSource,+oldEvent.getTarget());|1832335|如您所见，EventTarget通常始终保持不变。此外，子类可以覆盖copyFor，而其他子类，如MouseEvent，也可以定义重载。|1832336|但是，这些事件实际上是如何调度到EventHandler的呢？嗯，EventDispatcher的内部实现使它们成为EventHandler的一种“集合”。每个EventDispatcher跟踪所有的过滤器、处理程序和属性处理程序(onXXX)，这些过滤器、处理程序和属性处理程序(+Node)已经添加到其相关的源(例如Node)中或从其相关的源中删除。您的EventDispatcher不需要这样做，但它需要一种方法来访问您存储EventHandler的任何位置。|1832337|在捕获阶段，EventDispatcher调用通过addEventFilter(EventType,EventHandler)添加的所有适当的EventHandler。然后，在冒泡阶段，EventDispatcher调用通过addEventHandler(EventType,EventHandler)或setOnXXX添加的所有适当的EventHandler(例如setOnMouseClicked)。|1832338|我所说的适当是什么意思？|1832339|每个触发的Event都有一个关联的EventType。说EventType可能有一个超级EventType。例如，MouseEvent.MOUSE_ENTERED的“继承”树是：|1832340|Event.ANY
++++InputEvent.ANY
++++++++MouseEvent.ANY
++++++++++++MouseEvent.MOUSE_ENTERED_TARGET
++++++++++++++++MouseEvent.MOUSE_ENTERED|1832341|调度Event时，您必须调用为Event的EventType和所有EventType的超类型注册的所有EventType。此外，请注意，使用Event并不会停止当前EventDispatcher当前阶段对该EventHandler的处理，而是会完成对所有相应EventHandler的调用。但是，一旦该d86的该阶段完成，则停止对d87的处理。|1832342|无论您使用哪种机制来存储EventHandler，都必须能够由同一线程进行并发修改。这是因为EventHandler可以针对相同阶段的相同EventHandler向相同源添加或从相同源删除另一个EventType。如果您将它们存储在常规List中，这意味着在您迭代List时可能会对其进行修改。可以自行删除的EventHandler的一个现成示例是WeakEventHandler。如果WeakEventHandler在被“垃圾回收”后被调用，它将尝试删除自身。|1832343|此外，我不知道这是否是必需的，但是内部实现不允许为相同的源、EventType和阶段多次注册相同的EventHandler。但是请记住，通过addEventHandler添加的EventHandler和通过setOnXXX添加的and是分开处理的，即使它们都是在同一阶段(冒泡)调用的。此外，调用setOnXXX将替换以前为同一属性设置的任何EventHandler。|1832344|entityMap^0|0|3|5|K|B|17|5|1G|6|20|B|2F|5|2X|6|4G|5|4Q|E|58|C|0|0|F|0|0|4|5|E|5|K|4|Q|1J|2E|I|3B|5|3L|4|0|0|I|L|F|16|P|28|F|0|0|6|M|T|L|23|C|2W|5|3B|5|3R|I|4E|5|4P|9|51|5|62|5|6R|5|0|1|I|T|5|19|I|1V|F|2M|5|2S|6|36|C|3K|5|3U|C|4A|6|4L|C|51|6|59|H|5V|6|68|C|0|0|5|B|Y|7|1D|A|0|G|C|X|F|1M|C|28|F|38|5|3Y|4|4G|4|4Z|F|5Z|C|0|6|F|P|12|1Z|C|2L|F|34|13|48|8|4O|C|53|H|0|0|5|5|H|9|S|9|18|9|1L|O|0|0|2|5|F|5|L|9|X|9|1F|9|1Y|5|2A|F|2V|C|3L|C|0|C|C|1A|C|1X|C|2P|9|3A|4|3O|4|4A|C|4U|G|5D|G|0|U|9|1D|C|1Y|F|2G|C|2V|8|44|8|4R|C|0^^$0|@$1|2|3|4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1L|8|@$D|1M|E|1N|F|G]|$D|1O|E|1P|F|G]|$D|1Q|E|1R|F|G]|$D|1S|E|1T|F|G]|$D|1U|E|1V|F|G]|$D|1W|E|1X|F|G]|$D|1Y|E|1Z|F|G]|$D|20|E|21|F|G]|$D|22|E|23|F|G]|$D|24|E|25|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|26|8|@$D|27|E|28|F|G]]|9|@]|A|$]]|$1|J|3|K|5|L|7|29|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|2A|8|@$D|2B|E|2C|F|G]|$D|2D|E|2E|F|G]|$D|2F|E|2G|F|G]|$D|2H|E|2I|F|G]|$D|2J|E|2K|F|G]|$D|2L|E|2M|F|G]|$D|2N|E|2O|F|G]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|2P|8|@$D|2Q|E|2R|F|G]|$D|2S|E|2T|F|G]|$D|2U|E|2V|F|G]|$D|2W|E|2X|F|G]]|9|@]|A|$]]|$1|S|3|T|5|L|7|2Y|8|@]|9|@]|A|$M|N]]|$1|U|3|V|5|6|7|2Z|8|@$D|30|E|31|F|G]|$D|32|E|33|F|G]|$D|34|E|35|F|G]|$D|36|E|37|F|G]|$D|38|E|39|F|G]|$D|3A|E|3B|F|G]|$D|3C|E|3D|F|G]|$D|3E|E|3F|F|G]|$D|3G|E|3H|F|G]|$D|3I|E|3J|F|G]|$D|3K|E|3L|F|G]]|9|@]|A|$]]|$1|W|3|X|5|6|7|3M|8|@$D|3N|E|3O|F|G]|$D|3P|E|3Q|F|G]|$D|3R|E|3S|F|G]|$D|3T|E|3U|F|G]|$D|3V|E|3W|F|G]|$D|3X|E|3Y|F|G]|$D|3Z|E|40|F|G]|$D|41|E|42|F|G]|$D|43|E|44|F|G]|$D|45|E|46|F|G]|$D|47|E|48|F|G]|$D|49|E|4A|F|G]|$D|4B|E|4C|F|G]|$D|4D|E|4E|F|G]|$D|4F|E|4G|F|G]]|9|@]|A|$]]|$1|Y|3|Z|5|L|7|4H|8|@]|9|@]|A|$M|N]]|$1|10|3|11|5|6|7|4I|8|@$D|4J|E|4K|F|G]|$D|4L|E|4M|F|G]|$D|4N|E|4O|F|G]]|9|@]|A|$]]|$1|12|3|13|5|6|7|4P|8|@$D|4Q|E|4R|F|G]|$D|4S|E|4T|F|G]|$D|4U|E|4V|F|G]|$D|4W|E|4X|F|G]|$D|4Y|E|4Z|F|G]|$D|50|E|51|F|G]|$D|52|E|53|F|G]|$D|54|E|55|F|G]|$D|56|E|57|F|G]]|9|@]|A|$]]|$1|14|3|15|5|6|7|58|8|@$D|59|E|5A|F|G]|$D|5B|E|5C|F|G]|$D|5D|E|5E|F|G]|$D|5F|E|5G|F|G]|$D|5H|E|5I|F|G]|$D|5J|E|5K|F|G]|$D|5L|E|5M|F|G]|$D|5N|E|5O|F|G]]|9|@]|A|$]]|$1|16|3|17|5|6|7|5P|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|5Q|8|@$D|5R|E|5S|F|G]|$D|5T|E|5U|F|G]|$D|5V|E|5W|F|G]|$D|5X|E|5Y|F|G]|$D|5Z|E|60|F|G]]|9|@]|A|$]]|$1|1A|3|1B|5|L|7|61|8|@]|9|@]|A|$M|N]]|$1|1C|3|1D|5|6|7|62|8|@$D|63|E|64|F|G]|$D|65|E|66|F|G]|$D|67|E|68|F|G]|$D|69|E|6A|F|G]|$D|6B|E|6C|F|G]|$D|6D|E|6E|F|G]|$D|6F|E|6G|F|G]|$D|6H|E|6I|F|G]|$D|6J|E|6K|F|G]]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|6L|8|@$D|6M|E|6N|F|G]|$D|6O|E|6P|F|G]|$D|6Q|E|6R|F|G]|$D|6S|E|6T|F|G]|$D|6U|E|6V|F|G]|$D|6W|E|6X|F|G]|$D|6Y|E|6Z|F|G]|$D|70|E|71|F|G]|$D|72|E|73|F|G]]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|74|8|@$D|75|E|76|F|G]|$D|77|E|78|F|G]|$D|79|E|7A|F|G]|$D|7B|E|7C|F|G]|$D|7D|E|7E|F|G]|$D|7F|E|7G|F|G]|$D|7H|E|7I|F|G]]|9|@]|A|$]]|$1|1I|3|-4|5|6|7|7J|8|@]|9|@]|A|$]]]|1J|$]]

The first thing to realize is how JavaFX dispatches events.

When an <code>Event</code> is fired it has an associated <code>EventTarget</code>. If the target was in the scene-graph then the path of the <code>Event</code> starts at the <code>Window</code> and goes down the scene-graph until the <code>EventTarget</code> is reached. The <code>Event</code> then goes back up the scene-graph until it reaches the <code>Window</code> again. This is known as the "capturing phase" and the "bubbling phase", respectively. Event filters are invoked during the capturing phase and event handlers are invoked during the bubbling phase. The <code>EventHandler</code>s set using the <code>onXXX</code> properties (e.g. <code>onMouseClicked</code>) are special types of handlers (i.e. not filters).

The <code>EventDispatcher</code> interface has the following method:

<pre><code>public Event dispatchEvent(Event event, EventDispatChain tail) { ... }
</code></pre>

Here, the <code>event</code> is the <code>Event</code> being dispatched and the <code>tail</code> is the <code>EventDispatchChain</code> built, possibly recursively, by <code>EventTarget.buildEventDispatchChain(EventDispatchChain)</code>. This will return <code>null</code> if the <code>event</code> is consumed during execution of the method.

The <code>EventDispatchChain</code> is a stack of <code>EventDispatcher</code>s. Every time you call <code>tail.dispatchEvent(event)</code> you are essentially popping an <code>EventDispatcher</code> off the top and invoking it.

<pre><code>@Override
public Event dispatchEvent(Event event, EventDispatchChain tail) {
 // First, dispatch event for the capturing phase
 event = dispatchCapturingEvent(event);

 if (event.isConsumed()) {
 // One of the EventHandlers invoked in dispatchCapturingEvent
 // consumed the event. Return null to indicate processing is complete
 return null;
 }

 // Forward the event to the next EventDispatcher in the chain
 // (i.e. on the stack). This will start the "capturing" on the
 // next EventDispatcher. Returns null if event was consumed down
 // the chain
 event = tail.dispatchEvent(event);

 // once we've reached this point the capturing phase has completed

 if (event != null) {
 // Not consumed from down the chain so we now handle the
 // bubbling phase of the process
 event = dispatchBubblingEvent(event);

 if (event.isConsumed()) {
 // One of the EventHandlers invoked in dispatchBubblingEvent
 // consumed the event. Return null to indicate processing is complete
 return null;
 }
 }

 // return the event, or null if tail.dispatchEvent returned null
 return event;
}
</code></pre>

You're probably wondering where <code>dispatchCapturingEvent</code> and <code>dispatchBubblingEvent</code> are defined. These methods would be created by you and would invoke the appropriate <code>EventHandler</code>s. You might also be wondering why these methods return an <code>Event</code>. The reason is simple: During the processing of the <code>Event</code> these methods, along with <code>tail.dispatchEvent</code>, might alter the <code>Event</code>. Other than <code>consume()</code>, however, <code>Event</code> and its subclasses are basically immutable. This means any other alterations require the creation of a new <code>Event</code>. It is this new <code>Event</code> that should be used by the rest of the event-handling process.

The call to <code>tail.dispatchEvent</code> will virtually always return a new instance of the <code>Event</code>. This is due to the fact each <code>EventDispatcher</code> in the <code>EventDispatchChain</code> is normally associated with its own source (e.g. a <code>Label</code> or <code>Window</code>). When an <code>EventHandler</code> is being invoked the source of the <code>Event</code> must be the same <code>Object</code> that the <code>EventHandler</code> was registered to; if an <code>EventHandler</code> was registered with a <code>Window</code> then <code>event.getSource()</code> must return that <code>Window</code> during said <code>EventHandler</code>'s execution. The way this is achieved is by using the <code>Event.copyFor(Object,EventTarget)</code> method.

<pre><code>Event oldEvent = ...;
Event newEvent = oldEvent.copyFor(newSource, oldEvent.getTarget());
</code></pre>

As you can see, the <code>EventTarget</code> normally remains the same throughout. Also, subclasses may override <code>copyFor</code> while others, such as <code>MouseEvent</code>, may also define an overload.

How are the events actually dispatched to the <code>EventHandler</code>s though? Well, the internal implementation of <code>EventDispatcher</code> makes them a sort of "collection" of <code>EventHandler</code>s. Each <code>EventDispatcher</code> tracks all filters, handlers, and property-handlers (<code>onXXX</code>) that have been added to or removed from its associated source (e.g. <code>Node</code>). Your <code>EventDispatcher</code> doesn't have to do this but it will need a way to access wherever you do store the <code>EventHandler</code>s.

During the capturing phase the <code>EventDispatcher</code> invokes all the appropriate <code>EventHandler</code>s added via <code>addEventFilter(EventType,EventHandler)</code>. Then, during the bubbling phase, the <code>EventDispatcher</code> invokes all the appropriate <code>EventHandler</code>s added via <code>addEventHandler(EventType,EventHandler)</code> or <code>setOnXXX</code> (e.g. <code>setOnMouseClicked</code>). 

What do I mean by appropriate?

Every fired <code>Event</code> has an associated <code>EventType</code>. Said <code>EventType</code> may have a super <code>EventType</code>. For instance, the "inheritance" tree of <code>MouseEvent.MOUSE_ENTERED</code> is:

<pre class="lang-none prettyprint-override"><code>Event.ANY
 InputEvent.ANY
 MouseEvent.ANY
 MouseEvent.MOUSE_ENTERED_TARGET
 MouseEvent.MOUSE_ENTERED
</code></pre>

When dispatching an <code>Event</code> you have to invoke all the <code>EventHandler</code>s registered for the <code>Event</code>'s <code>EventType</code> and all the <code>EventType</code>'s supertypes. Also, note that consuming an <code>Event</code> does not stop processing of that <code>Event</code> for the current phase of the current <code>EventDispatcher</code> but instead finishes invoking all appropriate <code>EventHandler</code>s. Once that phase for that <code>EventDispatcher</code> has completed, however, the processing of the <code>Event</code> stops.

Whatever mechanism you use to store the <code>EventHandler</code>s must be capable of concurrent modification by the same thread. This is because an <code>EventHandler</code> may add or remove another <code>EventHandler</code> to or from the same source for the same <code>EventType</code> for the same phase. If you stored them in a regular <code>List</code> this means the <code>List</code> may be modified while you're iterating it. A readily available example of an <code>EventHandler</code> that may remove itself is <code>WeakEventHandler</code>. A <code>WeakEventHandler</code> will attempt to remove itself if it is invoked after it has been "garbage collected".

Also, I don't know if this is required, but the internal implementation doesn't allow the same <code>EventHandler</code> to be registered more than once for the same source, <code>EventType</code>, and phase. Remember, though, that the <code>EventHandler</code>s added via <code>addEventHandler</code> and those added via <code>setOnXXX</code> are handled separately even though they are both invoked during the same phase (bubbling). Also, calling <code>setOnXXX</code> replaces any previous <code>EventHandler</code> set for the same property.

Does anyone know how to write a custom Event Dispatcher based on the javafx.event package? I searched in Google &amp; Co. but didn't find a nice example.

Have anyone a minimalistic example for me? That would be nice - I tried it a few times to understand it, but I failed.

Custom Event Dispatcher - JavaFX

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

有人知道如何编写基于javafx.event包的自定义事件分派器吗？我在Google & Co.上搜索，但没有找到一个很好的例子。有没有人能给我举个简约的例子？那就太好了--我试了几次想要理解它，但是我失败了。

自定义事件分派器- JavaFX-腾讯云开发者社区-腾讯云

问自定义事件分派器- JavaFX
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问自定义事件分派器- JavaFXEN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问自定义事件分派器- JavaFX
EN