1# Event Distribution
2
3## Overview
4
5Event distribution in ArkUI refers to the process where ArkUI receives pointer events generated by user interactions and dispatches these events to the respective components through a hit test, forming an event chain.
6
7As an input from a touch test, a pointer event can be categorized into touch-type pointer events and mouse-type pointer events based on the user's interaction method.
8
9- Touch-type pointer events: These are pointer events generated by touch actions, with input sources including a finger, a stylus, a mouse device, and a touchpad. They can trigger touch events, tap events, drag events, and gesture events.
10
11- Mouse-type pointer events: These are pointer events generated by mouse operations, with input sources including a mouse device, a touchpad, and a joystick. They can trigger touch events, click events, drag events, gesture events, and mouse events.
12
13Regardless of whether it is a touch-type pointer event or a mouse-type pointer event, the final event triggered is determined by the hit test and dispatched to the component. The hit test dictates the generation of the ArkUI event response chain, the distribution of pointer events, and the triggering of component bound events.
14
15## Hit Test
16
17Hit testing occurs when ArkUI detects a touch-type pointer event or the start event of a mouse-type pointer event (for example, an event generated when a finger or a mouse cursor is pressed). Based on the coordinates of the received event, the process involves testing the response area of a component and gathering the event response chain.
18
19You can influence the touch testing process by setting the following attributes:
20
21- **hitTestBehavior**: controls hit testing.
22
23- **interceptTouch**: allows for custom interception of pointer events.
24
25- **responseRegion**: sets the touch targets for components.
26
27- **enabled**: enables or disables interactivity of components.
28
29- Security components
30
31- Other attribute settings: such as opacity and component availability
32
33### Basic Process of Hit Test
34
35  ![TouchTest](figures/TouchTest.png)
36
37The basic process of hit testing is as follows: Upon receiving the start event, the system traverses the component tree from top to bottom and from right to left, collects gestures and events bound to each component, and then integrates this information level by level up to the parent component, constructing a complete event response chain.
38
39As shown in the figure, when the start event is dispatched to the component, the component collects gestures and events bound to it, and then passes the collection result to the parent component until the root node is reached. If a component is transparent, has been removed from the component tree, or the event coordinates are outside the component's touch target, the collection process is not triggered, and the feedback received by the parent component is empty. In addition, all components collect gestures and events and send the results to the parent component.
40
41### Hit Test Control
42
43When [hit test control](../reference/apis-arkui/arkui-ts/ts-universal-attributes-hit-test-behavior.md) is bound to a component, it may affect the hit test of sibling nodes and parent and child nodes. The impact of the child component on the hit test of the parent component depends on the status of the last child component that is not blocked in the hit test.
44
45You can configure hit test control to block the hit test of the component itself or other components.
46
47- **HitTestMode.Default**: This mode is used by default when the **hitTestBehavior** attribute is not specified. In this mode, if the component itself is hit, it will block the touch testing of sibling components, but will not block the touch testing of child components.
48
49  ![hitTestModeDefault](figures/hitTestModeDefault.png)
50
51- **HitTestMode.None**: In this mode, the component neither receives events nor interferes with the touch testing of its sibling components or child components.
52
53  ![hitTestModeNone](figures/hitTestModeNone.png)
54
55- **HitTestMode.Block**: This mode blocks the touch testing of child components. If the component itself is hit during a touch test, it will also block the touch testing of sibling components and parent components.
56
57  ![hitTestModeBlock](figures/hitTestModeBlock.png)
58
59- **HitTestMode.Transparent**: This mode allows the component to participate in touch testing itself, without blocking the touch testing of sibling components or parent components.
60
61  ![hitTestModeTransparent](figures/hitTestModeTransparent.png)
62
63### Custom Event Interception
64
65When a user performs a press action, the callback for [custom event interception](../reference/apis-arkui/arkui-ts/ts-universal-attributes-on-touch-intercept.md) bound to the component is triggered. You can dynamically adjust the **hitTestBehavior** attribute of the component based on the application status to affect the hit test process.
66
67### Enable/Disable Control
68
69[Disabled](../reference/apis-arkui/arkui-ts/ts-universal-attributes-enable.md) components, including their children, do not initiate the hit test process; instead, they pass the events back to the parent to continue the hit test.
70
71### Touch Target Settings
72
73[Touch target settings](../reference/apis-arkui/arkui-ts/ts-universal-attributes-touch-target.md) are another impact factor in the hit test. According to the [basic process of hit test](#basic-process-of-hit-test), the gestures and events bound to a component are collected and enter the event response chain only when the coordinates of an event hit the touch target of the component. As such, you can adjust the touch target of the component to control the hit test process. If the touch target is set to **0**, or defined as an untouchable area, the event is directly sent back to the parent node for subsequent hit tests.
74
75### Security Components
76
77ArkUI provides security components, such as [LocationButton](../security/AccessToken/locationbutton.md), [PasteButton](../security/AccessToken/pastebutton.md) and [SaveButton](../security/AccessToken/savebutton.md).
78
79If a component has a higher [z-order](../reference/apis-arkui/arkui-ts/ts-universal-attributes-z-order.md) than a security component and covers it, the security component's touch events are sent directly to the parent node for further touch testing.
80
81## Event Response Chain Collection
82
83The event response chain is the outcome of the hit test. In ArkUI, the event response chain is collected based on the right subtree priority, which follows a post-order traversal process according to the layout hierarchy of components. The pseudocode implementation is as follows:
84
85```
86foreach(item=>(node.rbegin(),node.rend(){
87    item.TouchTest()
88}
89node.collectEvent()
90```
91
92In the example of response chain collection below, with all **hitTestBehavior** attributes set to **Default** in the component tree, if a user touches component 5, the response chain that is ultimately collected, in order, is 5, 3, 1.
93
94This is because component 3 has **hitTestBehavior** set to **Default**, which, upon capturing the event, blocks the collection from its sibling nodes, thereby preventing the collection of component 1's left subtree.
95
96  ![EventResponseChain](figures/EventResponseChain.png)
97