Re: views and mouse events troubles
Re: views and mouse events troubles
- Subject: Re: views and mouse events troubles
- From: Matt Neuburg <email@hidden>
- Date: Wed, 25 Oct 2006 16:48:50 -0700
- Thread-topic: views and mouse events troubles
On or about 10/25/06 2:48 PM, thus spake "Ivan Kourtev" <email@hidden>:
> 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"
>> <email@hidden>:
>>
>>> 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
>>>> <email@hidden> 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 = email@hidden, <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 = email@hidden, 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 = email@hidden, 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/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden