Re: Cocoa window messages in app being ported from Carbon
Re: Cocoa window messages in app being ported from Carbon
- Subject: Re: Cocoa window messages in app being ported from Carbon
- From: "Glenn L. Austin via Cocoa-dev" <email@hidden>
- Date: Sat, 10 Aug 2019 22:30:45 -0700
> On Aug 10, 2019, at 10:20 PM, Kurt Bigler via Cocoa-dev
> <email@hidden> wrote:
>
> On 8/10/19 3:04:13 PM, Rob Petrovec wrote:
>>> On Aug 10, 2019, at 3:38 PM, Uli Kusterer <email@hidden>
>>> wrote:
>>>
>>>> On 10. Aug 2019, at 19:03, Rob Petrovec via Cocoa-dev
>>>> <email@hidden <mailto:email@hidden>> wrote:
>>>>
>>>>> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev
>>>>> <email@hidden <mailto:email@hidden>> wrote:
>>>>>
>>>>> The NSView subclasses involved are receiving drawRect: messages but are
>>>>> not receiving mouseDown:.
>>>> You need to implement NSView -hitTest: to get mouseDown events.
>>>
>>>
>>> No, the default implementation does all you need and is perfectly fine.
>> I’ll repeat myself, the OP is not getting mouseDown on his NSView
>> subclass. So it isn’t perfectly fine in this case. If he wants mouseDown
>> events in his NSView subclass he needs to override hitTest to return self,
>> or whatever subview he wants to get mouseDown. There is no avoiding it.
>> The default implementation of NSView hitTest just loops through it’s
>> visible subviews and calls hitTest on each one that the passed in point is
>> inside. It is obviously recursive. If any of the subviews return a valid
>> view from their implementations of -hitTest: then that valid view is
>> returned up the call stack. Whatever view is returned from -hitTest: at the
>> top of the call stack will get first crack at the mouseDown event. Since
>> NSViews don’t have subviews by default, let alone one that returns a valid
>> view from hitTest, then the default implementation of an NSView -hitTest
>> will return nil. Semantics, I know...
>> Either way, instead of going back & forth on this, why don’t you try
>> implementing an NSView subclass without hitTest returning self and see if
>> that view gets -mouseDown:. Then override -hitTest in the view to return
>> self and see that the view does get -mouseDown. Then you will see that I am
>> correct. Thanks.
>
> It is always worth trying something trivial regardless of arguments.
>
> I implemented hitTest to return self in my NSView subclass. It made no
> difference.
>
> After that, I tried having hitTest call the super method to see what it
> returned. For the simpler version of my window nib with only one view the
> super method was returning self. For the more complex version of the window
> nib with 3 views (of the same class), my NSView subclass's hitTest got called
> 4 times. In 2 cases the super method returned self; in 2 other cases the
> super method returned 0. I did not look at further details but it seems
> likely that the default implementation actually checks whether the location
> is in the view and returns 0 otherwise.
>
> -Kurt
Personally, I'd check to make sure that the coordinate system for that view (or
the underlying layer) isn't resetting it's internal origin to something other
than {0,0}. While that shouldn't necessarily affect hit testing, there's
something unusual about that view -- origin is offset, view is disabled, view
doesn't accept user interaction...?
--
Glenn L. Austin, Computer Wizard and Race Car Driver <><
<http://www.austinsoft.com>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden