ps: You may be relatively new to viewTest (view hit test)...
When the user taps the screen (event occurs)
1. Find the first control to receive the event (control)
2. Distribute and find processing
3. Return until the event is passed to the application and is discarded.
Called event routing!
The response chain (responderChain) just talks back and does not tell you why the distribution starts from xx and how to deal with this event! responderChain only talks about delivery. Did not say, why the response chain starts from a certain view, why can't it start from another? The viewTest mechanism will answer you! ! !
Summary: After an event occurs, viewTest will select the first responder. Therefore viewHitTest includes the response chain.
viewTest will choose who to start
ResponderChain will decide how to deliver, and the combination is a complete event routing.
view provides
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event{
//This method is implemented by the system by default
}
If you really want to use it, you should override (override) it will change the starting point of the route.
First, when a finger hits the view, the bottom layer must be received by the window (that is, the first view calls this method)
Check whether this point is inside your frame. If it is, see if there are subviews! If so, call this method on the subview!
If not, return to yourself. According to this analogy, is it the top view in the view area where the click occurred? The answer is Yeah!!!
Give a scene __ If you put a btn on a view, but the position of the btn is outside the frame of the view, this is entirely possible for inexperienced programmers!
As long as you don't set clipToBounds to the view, you can see btn. However, btn cannot receive events!
The reason is here
Because when hitTest is called on btn, it is found that the click event is not inside its frame. So it was ignored...
The event will start from the parent view, and then pass it back. When btn is normally placed inside the view, btn will respond first, and hitTest will pass the event to it first! Then, only when btn does not respond.
The rules of responderChain will pass it back to the parent view
therefore__
hitTest determines where to start
and responderChain determines the rules of how to deliver
Finally, if an event is not consumed in the route, it will eventually be passed back to the application and be discarded and recycled!
Because a control consumes (exhausted) events. Just like a message, if someone accepts it, it no longer exists.
Of course, you can rewrite its event handling, let it call the super processing method after processing, and then pass it to the next level. Note that if this is the case, you have to rewrite all the classes in the system! ! !
By default, as long as a control responds, it will cosume consume this event and will not pass it to the parent class (parent view or parent controller)! Of course, if you want to post back, you probably need to rewrite the entire uikit and create your own framework. (What? It's almost impossible). . .
However, for example, in a very special case, you must return one level, then you can try to rewrite the touch processing method of that view! Then call nextResponder in it, then this view has the ability to respond to the event and pass the event again, but note that there is a delay.
Unless, you write the view processing method in an asynchronous block. Otherwise, your parent view must wait for you to process it before it can be received. Of course, you can also pass it first, depending on the location of your nextResponder
The above is just a personal opinion. If there is anything wrong, welcome to discuss and research together! ! !