hitTest: withEvet Call process
For example, if it is the current View A, there is also a viewB
If the hitTest method is not overridden, the system defaults to call viewA's hitest method first, and then call viewB's htest method.
The system calling process is exactly the same as the following method of rewriting hitest.
-(UIView*)hitTest:(CGPoint)point withEvent:(UIEvent *)event
{
if ([self pointInside:point withEvent:event]) {
}
else {
return nil;
}
for (UIView *subView in ) {
if ([subView hitTest:point withEvent:event]!=nil) {
return subView;
}
}
return self;
}
Once explained, if the hitest method is not rewritten, then the default hitest method of each UIVIeew is the above processing flow.
There is nothing to say about that.
But for some special processing, it won't work
Therefore, the reason why the hitTest method is usually to penetrate the upper UIview so that the touch event can reach the following uiview.
For example, view A and VIew B,
View b completely blocks view A, but I want view A to respond to clicking event when viewB is clicked. You can use the following method:
-(UIView*)hitTest:(CGPoint)point withEvent:(UIEvent *)event
{
if ([self pointInside:point withEvent:event]) {
NSLog(@"in view A");
return self;
}
else {
return nil;
}
}
In-depth
Let's go into the deeper, now there is an instance requirement interface as follows.
Window
-ViewA
-ButtonA
-ViewB
-ButtonB
Hierarchy: ViewB completely covers ButtonA, ButtonB is on ViewB, and now it needs to be implemented:
(1) Both Button and Button can respond to messages (2) ViewS can also receive touches messages received by ViewB (3) Do not allow ViewB (ButtonB) to receive messages.
(First parse, by default, click on the ButtonB area to process iOS message.
-ViewA
-ButtonA
-ViewB
-ButtonB
After clicking the ButtonB area, the processing process: start from ViewA and call hitTest in turn
The values of pointInside are:
ViewA：NO;
ViewB：YES;
ButtonB：YES；
ButtonB's subViews: NO;
Therefore, the hitTest of ButtonB's subViews returns nil, so the returned processing object is ButtonB itself. Next, we start processing the touches series methods, here is the method that calls ButtonB binding. After processing, the message stops and the whole process ends. )
analyze:
There are many ways to implement it. Here we disassemble the two requirements to implement it, because realizing 2 can satisfy 1.
In the implementation of requirement 1, ViewB covers ButtonA, so by default, ButtonA cannot receive messages, but in the message mechanism, the response to search for message starts from the parent View, so we can make a judgment in the hitTest method of ViewA. If the touch point is on ButtonA, ButtonA will be returned as a message processing object.
The code is as follows:
#pragma mark - hitTest
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event
{
// When touch point is on _btn, hitTest returns _btn
CGPoint btnPointInA = [_btn convertPoint:point fromView:self];
if ([_btn pointInside:btnPointInA withEvent:event]) {
return _btn;
}
// Otherwise, return to default processing
return [super hitTest:point withEvent:event];
}
In this way, when the touch point is on ButtonA, the touch message is intercepted on ViewA and ViewB cannot be received. Then ButtonA receives a touch message, which triggers the onClick method.
The implementation of requirement 2, mentioned above, the response chain, ViewB only needs to override the touches series method, and then after processing it itself, pass the message to the next responder (i.e., parent View, ViewA).
The code is as follows: in the ViewB code
#pragma mark - touches
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
NSLog(@"B - touchesBeagan..");
// Pass the event to the parent View or the ViewController containing it
[ touchesBegan:touches withEvent:event];
}
- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event
{
NSLog(@"B - touchesCancelled..");
// Pass the event to the parent View or the ViewController containing it
[ touchesBegan:touches withEvent:event];
}
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
NSLog(@"B - touchesEnded..");
// Pass the event to the parent View or the ViewController containing it
[ touchesBegan:touches withEvent:event];
}
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
NSLog(@"B - touchesMoved..");
// Pass the event to the parent View or the ViewController containing it
[ touchesBegan:touches withEvent:event];
}
Then, you can receive the touches message on ViewA and write it on ViewA:
#pragma mark - touches
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
NSLog(@"A - touchesBeagan..");
}
- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event
{
NSLog(@"A - touchesCancelled..");
}
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
NSLog(@"A - touchesEnded..");
}
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
NSLog(@"A - touchesMoved..");
}
This enables the transmission of messages to the parent View.
To prevent ViewB from receiving messages, you can set =NO; in addition to this, you can also override ViewB's ponitInside, refer to the above principle.
Write on ViewB:
- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event
{
// This View does not respond to user events
return NO;
}