Re: views and mouse events troubles
Re: views and mouse events troubles
- Subject: Re: views and mouse events troubles
- From: Ivan Kourtev <email@hidden>
- Date: Wed, 25 Oct 2006 17:48:52 -0400
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"
<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/
_______________________________________________
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