views and mouse events troubles

  • Could someone please help and explain (or point to a document which
    explains) under what conditions do multiple views get the same mouse
    event?  I have a view containing another and when I click on the
    contained view both it and the containing view get the mouse event.

    Is that normal?  Based on all the docs I've read only one view should
    get the mouse event, or am I wrong to assume so?

    I tried many combinations (creating and inserting views into the
    hierarchy programmatically, or via IB, etc.) and nothing seems to
    affect things.  If I have N number of views under the mouse pointer
    (contained into each other), then all N of them get the mouse event.
    All view are non-transparent, and completely draw their background.

    Thanks for any help..

    -- ivan
  • On Wed, 25 Oct 2006 14:54:57 -0400, Ivan Kourtev <isk_lists...> said:
    > Could someone please help and explain (or point to a document which
    > explains) under what conditions do multiple views get the same mouse
    > event?  I have a view containing another and when I click on the
    > contained view both it and the containing view get the mouse event.
    >
    > Is that normal?  Based on all the docs I've read only one view should
    > get the mouse event, or am I wrong to assume so?
    >
    > I tried many combinations (creating and inserting views into the
    > hierarchy programmatically, or via IB, etc.) and nothing seems to
    > affect things.  If I have N number of views under the mouse pointer
    > (contained into each other), then all N of them get the mouse event.
    > All view are non-transparent, and completely draw their background.

    You are probably misunderstanding your own code.

    Look. I put an NSView inside another NSView. Each has a mouseUp method that
    logs. I clicked repeatedly in the window, the first click in the middle
    (where the view1 is) and the next to its right until finally I was clicking
    on the view2 (and not on the view1). Here is the log:

    2006-10-25 12:26:14.815 hitTestTest[733] view1: {226, 171}
    2006-10-25 12:26:16.542 hitTestTest[733] view1: {248, 173}
    2006-10-25 12:26:18.054 hitTestTest[733] view1: {273, 174}
    2006-10-25 12:26:20.238 hitTestTest[733] view2: {302, 173}
    2006-10-25 12:26:23.574 hitTestTest[733] view2: {310, 174}

    So, as you can see, for each click, only one NSView gets the event - the one
    that is deepest inside the view hierarchy ("frontmost", as it were).

    Pretty simple to test, as you see.

    Now, my guess is that you are misinterpreting the behavior of how hitTest
    messages are sent. But hitTest is not a mouse event! It's a preparation for
    sending a mouse event, which is a very different thing. So, for a single
    click in view1, we get this logging:

    2006-10-25 12:31:34.425 hitTestTest[769] view2 took a hittest
    2006-10-25 12:31:34.426 hitTestTest[769] view1 took a hittest
    2006-10-25 12:31:34.521 hitTestTest[769] view1: {228, 181}

    So both views are consulted with hitTest - because one of them might want to
    override the normal behavior - but only one view gets a mouse event. m.

    --
    matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
    A fool + a tool + an autorelease pool = cool!
    AppleScript: the Definitive Guide - Second Edition!
    <http://www.amazon.com/gp/product/0596102119>
  • I understand what you are saying about hitTest but I don't think this
    is the problem.  I wrote a small app to test and you can get it from
    http://homepage.mac.com/ikourtev/FileSharing6.html (it's called
    ViewTestA).  All MyViewA views are red and all MyViewB views are green.

    I overrode mouseUp and mouseDown in both MyViewA and MyViewB -- if I
    watch the log it suggests that more than one view can get mouse events.

    I understand that hitTest is sent from the window to many of the
    views in the hierarchy.  Actually I see a lot of hitTest's sent to
    views that are certainly out of the hierarchy -- I wonder if this is
    a problem too?

    Anyhow, maybe someone can take a look at the test app I mentioned
    above and tell me what's wrong with it.

    --
    ivan

    On Oct 25, 2006, at 3:33 PM, Matt Neuburg wrote:

    > On Wed, 25 Oct 2006 14:54:57 -0400, Ivan Kourtev
    > <isk_lists...> said:
    >> Could someone please help and explain (or point to a document which
    >> explains) under what conditions do multiple views get the same mouse
    >> event?  I have a view containing another and when I click on the
    >> contained view both it and the containing view get the mouse event.
    >>
    >> Is that normal?  Based on all the docs I've read only one view should
    >> get the mouse event, or am I wrong to assume so?
    >>
    >> I tried many combinations (creating and inserting views into the
    >> hierarchy programmatically, or via IB, etc.) and nothing seems to
    >> affect things.  If I have N number of views under the mouse pointer
    >> (contained into each other), then all N of them get the mouse event.
    >> All view are non-transparent, and completely draw their background.
    >
    > You are probably misunderstanding your own code.
    >
    > Look. I put an NSView inside another NSView. Each has a mouseUp
    > method that
    > logs. I clicked repeatedly in the window, the first click in the
    > middle
    > (where the view1 is) and the next to its right until finally I was
    > clicking
    > on the view2 (and not on the view1). Here is the log:
    >
    > 2006-10-25 12:26:14.815 hitTestTest[733] view1: {226, 171}
    > 2006-10-25 12:26:16.542 hitTestTest[733] view1: {248, 173}
    > 2006-10-25 12:26:18.054 hitTestTest[733] view1: {273, 174}
    > 2006-10-25 12:26:20.238 hitTestTest[733] view2: {302, 173}
    > 2006-10-25 12:26:23.574 hitTestTest[733] view2: {310, 174}
    >
    > So, as you can see, for each click, only one NSView gets the event
    > - the one
    > that is deepest inside the view hierarchy ("frontmost", as it were).
    >
    > Pretty simple to test, as you see.
    >
    > Now, my guess is that you are misinterpreting the behavior of how
    > hitTest
    > messages are sent. But hitTest is not a mouse event! It's a
    > preparation for
    > sending a mouse event, which is a very different thing. So, for a
    > single
    > click in view1, we get this logging:
    >
    > 2006-10-25 12:31:34.425 hitTestTest[769] view2 took a hittest
    > 2006-10-25 12:31:34.426 hitTestTest[769] view1 took a hittest
    > 2006-10-25 12:31:34.521 hitTestTest[769] view1: {228, 181}
    >
    > So both views are consulted with hitTest - because one of them
    > might want to
    > override the normal behavior - but only one view gets a mouse
    > event. m.
    >
    > --
    > matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
    > A fool + a tool + an autorelease pool = cool!
    > AppleScript: the Definitive Guide - Second Edition!
    > <http://www.amazon.com/gp/product/0596102119>
    >
    >
    >
  • On or about 10/25/06 1:01 PM, thus spake "Ivan Kourtev" <isk_lists...>:

    > I understand what you are saying about hitTest but I don't think this
    > is the problem.  I wrote a small app to test and you can get it from
    > http://homepage.mac.com/ikourtev/FileSharing6.html (it's called
    > ViewTestA).  All MyViewA views are red and all MyViewB views are green.
    >
    > I overrode mouseUp and mouseDown in both MyViewA and MyViewB -- if I
    > watch the log it suggests that more than one view can get mouse events.
    >
    > I understand that hitTest is sent from the window to many of the
    > views in the hierarchy.  Actually I see a lot of hitTest's sent to
    > views that are certainly out of the hierarchy -- I wonder if this is
    > a problem too?
    >
    > Anyhow, maybe someone can take a look at the test app I mentioned
    > above and tell me what's wrong with it.

    I looked and I still say I was right the first time - you don't understand
    your own code. I replaced the bizarre code in your mouseUp and mouseDown
    methods with this sort of thing:

    - (void)mouseDown:(NSEvent*)event
    {
        NSLog(@"mouseDown to %p", self);
    }

    Sure enough, when I click, this is the sort of thing I see:

    2006-10-25 14:19:42.672 ViewTestA[965] -[MyViewB hitTest:] >> self =
    0x321800, result = 0x0
    2006-10-25 14:19:42.673 ViewTestA[965] -[MyViewA hitTest:] >> self =
    0x342ab0, result = 0x342ab0
    2006-10-25 14:19:42.673 ViewTestA[965] -[MyViewB hitTest:] >> self =
    0x342ec0, result = 0x342ab0
    2006-10-25 14:19:42.673 ViewTestA[965] -[MyViewA hitTest:] >> self =
    0x343190, result = 0x342ab0
    2006-10-25 14:19:42.673 ViewTestA[965] mouseDown to 0x342ab0
    2006-10-25 14:19:42.776 ViewTestA[965] mouseUp to 0x342ab0

    So, you see, hitTest works correctly and so do mouseDown and mouseUp. Only
    one view gets mouseDown and mouseUp. Lots of views get hitTest, but if you
    read the docs you'll see why this is. So I would suggest you stop concerning
    yourself with hitTest (it is *very* rare that anyone needs to know anything
    about it) and be careful with how you write and interpret your own tests. If
    you want to know about mouseUp, log in a way that tells you if you're
    getting a mouseUp. m.

    > On Oct 25, 2006, at 3:33 PM, Matt Neuburg wrote:
    >
    >> On Wed, 25 Oct 2006 14:54:57 -0400, Ivan Kourtev
    >> <isk_lists...> said:
    >>> Could someone please help and explain (or point to a document which
    >>> explains) under what conditions do multiple views get the same mouse
    >>> event?  I have a view containing another and when I click on the
    >>> contained view both it and the containing view get the mouse event.
    >>>
    >>> Is that normal?  Based on all the docs I've read only one view should
    >>> get the mouse event, or am I wrong to assume so?
    >>>
    >>> I tried many combinations (creating and inserting views into the
    >>> hierarchy programmatically, or via IB, etc.) and nothing seems to
    >>> affect things.  If I have N number of views under the mouse pointer
    >>> (contained into each other), then all N of them get the mouse event.
    >>> All view are non-transparent, and completely draw their background.
    >>
    >> You are probably misunderstanding your own code.
    >>
    >> Look. I put an NSView inside another NSView. Each has a mouseUp
    >> method that
    >> logs. I clicked repeatedly in the window, the first click in the
    >> middle
    >> (where the view1 is) and the next to its right until finally I was
    >> clicking
    >> on the view2 (and not on the view1). Here is the log:
    >>
    >> 2006-10-25 12:26:14.815 hitTestTest[733] view1: {226, 171}
    >> 2006-10-25 12:26:16.542 hitTestTest[733] view1: {248, 173}
    >> 2006-10-25 12:26:18.054 hitTestTest[733] view1: {273, 174}
    >> 2006-10-25 12:26:20.238 hitTestTest[733] view2: {302, 173}
    >> 2006-10-25 12:26:23.574 hitTestTest[733] view2: {310, 174}
    >>
    >> So, as you can see, for each click, only one NSView gets the event
    >> - the one
    >> that is deepest inside the view hierarchy ("frontmost", as it were).
    >>
    >> Pretty simple to test, as you see.
    >>
    >> Now, my guess is that you are misinterpreting the behavior of how
    >> hitTest
    >> messages are sent. But hitTest is not a mouse event! It's a
    >> preparation for
    >> sending a mouse event, which is a very different thing. So, for a
    >> single
    >> click in view1, we get this logging:
    >>
    >> 2006-10-25 12:31:34.425 hitTestTest[769] view2 took a hittest
    >> 2006-10-25 12:31:34.426 hitTestTest[769] view1 took a hittest
    >> 2006-10-25 12:31:34.521 hitTestTest[769] view1: {228, 181}
    >>
    >> So both views are consulted with hitTest - because one of them
    >> might want to
    >> override the normal behavior - but only one view gets a mouse
    >> event. m.
    >>
    >> --
    >> matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
    >> A fool + a tool + an autorelease pool = cool!
    >> AppleScript: the Definitive Guide - Second Edition!
    >> <http://www.amazon.com/gp/product/0596102119>
    >>
    >>
    >>
    >

    --
    matt neuburg, phd = <matt...>, http://www.tidbits.com/matt/
    pantes anthropoi tou eidenai oregontai phusei
    AppleScript: the Definitive Guide - Second Edition!
    http://www.amazon.com/gp/product/0596102119
    Take Control of Word 2004, Tiger, and more -
    http://www.takecontrolbooks.com/tiger-customizing.html
    Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/
  • Ok, so I finally got it, thanks.

    So can it be safely inferred that passing mouseUp and mouseDowns up
    to super (like this):

    - (void)mouseDown:(NSEvent*)event {  [super mouseDown:event]; }

    was causing the event to get passed up to the enclosing view?
    Regarding hitTest, I thought I needed to be concerned with it because
    I am trying to implement "view transparency," that is having an
    enclosing view (certainly not the topmost under mouse) handle the
    event.  So which approach is better for that:

    (a) call [super mouseXX...

    or

    (b) reimplement hitTest to return something other than self?

    --
    ivan

    On Oct 25, 2006, at 5:25 PM, Matt Neuburg wrote:

    > On or about 10/25/06 1:01 PM, thus spake "Ivan Kourtev"
    > <isk_lists...>:
    >
    >> I understand what you are saying about hitTest but I don't think this
    >> is the problem.  I wrote a small app to test and you can get it from
    >> http://homepage.mac.com/ikourtev/FileSharing6.html (it's called
    >> ViewTestA).  All MyViewA views are red and all MyViewB views are
    >> green.
    >>
    >> I overrode mouseUp and mouseDown in both MyViewA and MyViewB -- if I
    >> watch the log it suggests that more than one view can get mouse
    >> events.
    >>
    >> I understand that hitTest is sent from the window to many of the
    >> views in the hierarchy.  Actually I see a lot of hitTest's sent to
    >> views that are certainly out of the hierarchy -- I wonder if this is
    >> a problem too?
    >>
    >> Anyhow, maybe someone can take a look at the test app I mentioned
    >> above and tell me what's wrong with it.
    >
    > I looked and I still say I was right the first time - you don't
    > understand
    > your own code. I replaced the bizarre code in your mouseUp and
    > mouseDown
    > methods with this sort of thing:
    >
    > - (void)mouseDown:(NSEvent*)event
    > {
    > NSLog(@"mouseDown to %p", self);
    > }
    >
    > Sure enough, when I click, this is the sort of thing I see:
    >
    > 2006-10-25 14:19:42.672 ViewTestA[965] -[MyViewB hitTest:] >> self =
    > 0x321800, result = 0x0
    > 2006-10-25 14:19:42.673 ViewTestA[965] -[MyViewA hitTest:] >> self =
    > 0x342ab0, result = 0x342ab0
    > 2006-10-25 14:19:42.673 ViewTestA[965] -[MyViewB hitTest:] >> self =
    > 0x342ec0, result = 0x342ab0
    > 2006-10-25 14:19:42.673 ViewTestA[965] -[MyViewA hitTest:] >> self =
    > 0x343190, result = 0x342ab0
    > 2006-10-25 14:19:42.673 ViewTestA[965] mouseDown to 0x342ab0
    > 2006-10-25 14:19:42.776 ViewTestA[965] mouseUp to 0x342ab0
    >
    > So, you see, hitTest works correctly and so do mouseDown and
    > mouseUp. Only
    > one view gets mouseDown and mouseUp. Lots of views get hitTest, but
    > if you
    > read the docs you'll see why this is. So I would suggest you stop
    > concerning
    > yourself with hitTest (it is *very* rare that anyone needs to know
    > anything
    > about it) and be careful with how you write and interpret your own
    > tests. If
    > you want to know about mouseUp, log in a way that tells you if you're
    > getting a mouseUp. m.
    >
    >> On Oct 25, 2006, at 3:33 PM, Matt Neuburg wrote:
    >>
    >>> On Wed, 25 Oct 2006 14:54:57 -0400, Ivan Kourtev
    >>> <isk_lists...> said:
    >>>> Could someone please help and explain (or point to a document which
    >>>> explains) under what conditions do multiple views get the same
    >>>> mouse
    >>>> event?  I have a view containing another and when I click on the
    >>>> contained view both it and the containing view get the mouse event.
    >>>>
    >>>> Is that normal?  Based on all the docs I've read only one view
    >>>> should
    >>>> get the mouse event, or am I wrong to assume so?
    >>>>
    >>>> I tried many combinations (creating and inserting views into the
    >>>> hierarchy programmatically, or via IB, etc.) and nothing seems to
    >>>> affect things.  If I have N number of views under the mouse pointer
    >>>> (contained into each other), then all N of them get the mouse
    >>>> event.
    >>>> All view are non-transparent, and completely draw their background.
    >>>
    >>> You are probably misunderstanding your own code.
    >>>
    >>> Look. I put an NSView inside another NSView. Each has a mouseUp
    >>> method that
    >>> logs. I clicked repeatedly in the window, the first click in the
    >>> middle
    >>> (where the view1 is) and the next to its right until finally I was
    >>> clicking
    >>> on the view2 (and not on the view1). Here is the log:
    >>>
    >>> 2006-10-25 12:26:14.815 hitTestTest[733] view1: {226, 171}
    >>> 2006-10-25 12:26:16.542 hitTestTest[733] view1: {248, 173}
    >>> 2006-10-25 12:26:18.054 hitTestTest[733] view1: {273, 174}
    >>> 2006-10-25 12:26:20.238 hitTestTest[733] view2: {302, 173}
    >>> 2006-10-25 12:26:23.574 hitTestTest[733] view2: {310, 174}
    >>>
    >>> So, as you can see, for each click, only one NSView gets the event
    >>> - the one
    >>> that is deepest inside the view hierarchy ("frontmost", as it were).
    >>>
    >>> Pretty simple to test, as you see.
    >>>
    >>> Now, my guess is that you are misinterpreting the behavior of how
    >>> hitTest
    >>> messages are sent. But hitTest is not a mouse event! It's a
    >>> preparation for
    >>> sending a mouse event, which is a very different thing. So, for a
    >>> single
    >>> click in view1, we get this logging:
    >>>
    >>> 2006-10-25 12:31:34.425 hitTestTest[769] view2 took a hittest
    >>> 2006-10-25 12:31:34.426 hitTestTest[769] view1 took a hittest
    >>> 2006-10-25 12:31:34.521 hitTestTest[769] view1: {228, 181}
    >>>
    >>> So both views are consulted with hitTest - because one of them
    >>> might want to
    >>> override the normal behavior - but only one view gets a mouse
    >>> event. m.
    >>>
    >>> --
    >>> matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
    >>> A fool + a tool + an autorelease pool = cool!
    >>> AppleScript: the Definitive Guide - Second Edition!
    >>> <http://www.amazon.com/gp/product/0596102119>
    >>>
    >>>
    >>>
    >>
    >
    > --
    > matt neuburg, phd = <matt...>, http://www.tidbits.com/matt/
    > pantes anthropoi tou eidenai oregontai phusei
    > AppleScript: the Definitive Guide - Second Edition!
    > http://www.amazon.com/gp/product/0596102119
    > Take Control of Word 2004, Tiger, and more -
    > http://www.takecontrolbooks.com/tiger-customizing.html
    > Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/
    >
    >
    >
  • On or about 10/25/06 2:48 PM, thus spake "Ivan Kourtev" <isk_lists...>:

    > Ok, so I finally got it, thanks.
    >
    > So can it be safely inferred that passing mouseUp and mouseDowns up
    > to super (like this):
    >
    > - (void)mouseDown:(NSEvent*)event {  [super mouseDown:event]; }
    >
    > was causing the event to get passed up to the enclosing view?

    Sure, but there's no need to "infer". The manual says so, directly:

    "mouseUp: Informs the receiver that the user has released the left mouse
    button... The default implementation simply passes this message to the next
    responder."

    So, first you provided your own implementation, then you called super's
    implementation, which passed the message to the next responder. The next
    responder is the enclosing view.

    > Regarding hitTest, I thought I needed to be concerned with it because
    > I am trying to implement "view transparency," that is having an
    > enclosing view (certainly not the topmost under mouse) handle the
    > event.  So which approach is better for that:
    >
    > (a) call [super mouseXX...
    >
    > or
    >
    > (b) reimplement hitTest to return something other than self?

    I think this is a matter partly of personal preference and partly of what
    works. If you were to implement mouseDown and mouseUp, it is the subview
    that would implement them. If you were to reimplement hitTest, it is the
    superview that would reimplement it. Who is it that should know that these
    subviews are special, the subviews themselves or their superview? You might
    rather it be subviews themselves. But of course if it turns out that calling
    super mouseXX just doesn't work properly, then the answer is clear by
    process of elimination. m.

    > On Oct 25, 2006, at 5:25 PM, Matt Neuburg wrote:
    >
    >> On or about 10/25/06 1:01 PM, thus spake "Ivan Kourtev"
    >> <isk_lists...>:
    >>
    >>> I understand what you are saying about hitTest but I don't think this
    >>> is the problem.  I wrote a small app to test and you can get it from
    >>> http://homepage.mac.com/ikourtev/FileSharing6.html (it's called
    >>> ViewTestA).  All MyViewA views are red and all MyViewB views are
    >>> green.
    >>>
    >>> I overrode mouseUp and mouseDown in both MyViewA and MyViewB -- if I
    >>> watch the log it suggests that more than one view can get mouse
    >>> events.
    >>>
    >>> I understand that hitTest is sent from the window to many of the
    >>> views in the hierarchy.  Actually I see a lot of hitTest's sent to
    >>> views that are certainly out of the hierarchy -- I wonder if this is
    >>> a problem too?
    >>>
    >>> Anyhow, maybe someone can take a look at the test app I mentioned
    >>> above and tell me what's wrong with it.
    >>
    >> I looked and I still say I was right the first time - you don't
    >> understand
    >> your own code. I replaced the bizarre code in your mouseUp and
    >> mouseDown
    >> methods with this sort of thing:
    >>
    >> - (void)mouseDown:(NSEvent*)event
    >> {
    >> NSLog(@"mouseDown to %p", self);
    >> }
    >>
    >> Sure enough, when I click, this is the sort of thing I see:
    >>
    >> 2006-10-25 14:19:42.672 ViewTestA[965] -[MyViewB hitTest:] >> self =
    >> 0x321800, result = 0x0
    >> 2006-10-25 14:19:42.673 ViewTestA[965] -[MyViewA hitTest:] >> self =
    >> 0x342ab0, result = 0x342ab0
    >> 2006-10-25 14:19:42.673 ViewTestA[965] -[MyViewB hitTest:] >> self =
    >> 0x342ec0, result = 0x342ab0
    >> 2006-10-25 14:19:42.673 ViewTestA[965] -[MyViewA hitTest:] >> self =
    >> 0x343190, result = 0x342ab0
    >> 2006-10-25 14:19:42.673 ViewTestA[965] mouseDown to 0x342ab0
    >> 2006-10-25 14:19:42.776 ViewTestA[965] mouseUp to 0x342ab0
    >>
    >> So, you see, hitTest works correctly and so do mouseDown and
    >> mouseUp. Only
    >> one view gets mouseDown and mouseUp. Lots of views get hitTest, but
    >> if you
    >> read the docs you'll see why this is. So I would suggest you stop
    >> concerning
    >> yourself with hitTest (it is *very* rare that anyone needs to know
    >> anything
    >> about it) and be careful with how you write and interpret your own
    >> tests. If
    >> you want to know about mouseUp, log in a way that tells you if you're
    >> getting a mouseUp. m.
    >>
    >>> On Oct 25, 2006, at 3:33 PM, Matt Neuburg wrote:
    >>>
    >>>> On Wed, 25 Oct 2006 14:54:57 -0400, Ivan Kourtev
    >>>> <isk_lists...> said:
    >>>>> Could someone please help and explain (or point to a document which
    >>>>> explains) under what conditions do multiple views get the same
    >>>>> mouse
    >>>>> event?  I have a view containing another and when I click on the
    >>>>> contained view both it and the containing view get the mouse event.
    >>>>>
    >>>>> Is that normal?  Based on all the docs I've read only one view
    >>>>> should
    >>>>> get the mouse event, or am I wrong to assume so?
    >>>>>
    >>>>> I tried many combinations (creating and inserting views into the
    >>>>> hierarchy programmatically, or via IB, etc.) and nothing seems to
    >>>>> affect things.  If I have N number of views under the mouse pointer
    >>>>> (contained into each other), then all N of them get the mouse
    >>>>> event.
    >>>>> All view are non-transparent, and completely draw their background.
    >>>>
    >>>> You are probably misunderstanding your own code.
    >>>>
    >>>> Look. I put an NSView inside another NSView. Each has a mouseUp
    >>>> method that
    >>>> logs. I clicked repeatedly in the window, the first click in the
    >>>> middle
    >>>> (where the view1 is) and the next to its right until finally I was
    >>>> clicking
    >>>> on the view2 (and not on the view1). Here is the log:
    >>>>
    >>>> 2006-10-25 12:26:14.815 hitTestTest[733] view1: {226, 171}
    >>>> 2006-10-25 12:26:16.542 hitTestTest[733] view1: {248, 173}
    >>>> 2006-10-25 12:26:18.054 hitTestTest[733] view1: {273, 174}
    >>>> 2006-10-25 12:26:20.238 hitTestTest[733] view2: {302, 173}
    >>>> 2006-10-25 12:26:23.574 hitTestTest[733] view2: {310, 174}
    >>>>
    >>>> So, as you can see, for each click, only one NSView gets the event
    >>>> - the one
    >>>> that is deepest inside the view hierarchy ("frontmost", as it were).
    >>>>
    >>>> Pretty simple to test, as you see.
    >>>>
    >>>> Now, my guess is that you are misinterpreting the behavior of how
    >>>> hitTest
    >>>> messages are sent. But hitTest is not a mouse event! It's a
    >>>> preparation for
    >>>> sending a mouse event, which is a very different thing. So, for a
    >>>> single
    >>>> click in view1, we get this logging:
    >>>>
    >>>> 2006-10-25 12:31:34.425 hitTestTest[769] view2 took a hittest
    >>>> 2006-10-25 12:31:34.426 hitTestTest[769] view1 took a hittest
    >>>> 2006-10-25 12:31:34.521 hitTestTest[769] view1: {228, 181}
    >>>>
    >>>> So both views are consulted with hitTest - because one of them
    >>>> might want to
    >>>> override the normal behavior - but only one view gets a mouse
    >>>> event. m.
    >>>>
    >>>> --
    >>>> matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
    >>>> A fool + a tool + an autorelease pool = cool!
    >>>> AppleScript: the Definitive Guide - Second Edition!
    >>>> <http://www.amazon.com/gp/product/0596102119>
    >>>>
    >>>>
    >>>>
    >>>
    >>
    >> --
    >> matt neuburg, phd = <matt...>, http://www.tidbits.com/matt/
    >> pantes anthropoi tou eidenai oregontai phusei
    >> AppleScript: the Definitive Guide - Second Edition!
    >> http://www.amazon.com/gp/product/0596102119
    >> Take Control of Word 2004, Tiger, and more -
    >> http://www.takecontrolbooks.com/tiger-customizing.html
    >> Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/
    >>
    >>
    >>
    >

    --
    matt neuburg, phd = <matt...>, http://www.tidbits.com/matt/
    pantes anthropoi tou eidenai oregontai phusei
    AppleScript: the Definitive Guide - Second Edition!
    http://www.amazon.com/gp/product/0596102119
    Take Control of Word 2004, Tiger, and more -
    http://www.takecontrolbooks.com/tiger-customizing.html
    Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/
previous month october 2006 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today