officescan客户端迁移和升级

URL:http://stackoverflow.com/questions/4961386/event-handling-for-ios-how-hittestwithevent-and-pointinsidewithevent-are-r
The implementation of

hitTest:withEvent:

in UIResponder does the following:It calls

pointInside:withEvent:

of

self

If the return is NO,

hitTest:withEvent:

returns

nil

. the end of the story.

If the return is YES, it sends

hitTest:withEvent:

messages to its subviews. it starts from the top-level subview, and continues to other views until a subview returns a non-

nil

object, or all subviews receive the message.

If a subview returns a non-

nil

object in the first time, the first

hitTest:withEvent:

returns that object. the end of the story.

If no subview returns a non-

nil

object, the first

hitTest:withEvent:

returns

self

This process repeats recursively, so normally the leaf view of the view hierarchy is returned eventually.However, you might override

hitTest:withEvent

to do something differently. In many cases, overriding

pointInside:withEvent:

is simpler and still provides enough options to tweak event handling in your application.

I think you are confusing subclassing with the view hierarchy. What the doc says is as follows. Say you have this view hierarchy. By hierarchy I'm not talking about class hierarchy, but views within views hierarchy, as follows:

you put your finger inside

D

. Here's what will happen:

hitTest:withEvent:

is called on

A

, the top-most view of the view hierarchy.

pointInside:withEvent:

is called recursively on each view.

pointInside:withEvent:

is called on

A

, and returns

YES

pointInside:withEvent:

is called on

B

, and returns

NO

pointInside:withEvent:

is called on

C

, and returns

YES

pointInside:withEvent:

is called on

D

, and returns

YES

On the views that returned

YES

, it will look down on the hierarchy to see the subview where the touch took place. In this case, from

A

,

C

and

D

, it will be

D

.

D

will be the hit-test view