• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa window messages in app being ported from Carbon
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa window messages in app being ported from Carbon


  • Subject: Re: Cocoa window messages in app being ported from Carbon
  • From: Kurt Bigler via Cocoa-dev <email@hidden>
  • Date: Sat, 10 Aug 2019 22:32:55 -0700

On 8/10/19 10:20:34 PM, Kurt Bigler via Cocoa-dev wrote:
On 8/10/19 3:04:13 PM, Rob Petrovec wrote:
    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.

Because of the other behavior I reported re Window resizing and splitter dragging not working once the window is frontmost, I implemented acceptsFirstMouse, returning YES.

The result is that my view now receives mouseDown in the same circumstances in which the other functions work: when the window is not frontmost.

So it seems somehow the window is being disabled once it is brought to front, either by a click or programmatically via makeKeyAndOrderFront.

Thanks to all for the fantastic help so far, on the weekend no less. I might have been utterly stuck for a long time without it. I'm still stuck but I have a couple good things to try.

-Kurt

_______________________________________________

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

References: 
 >Cocoa window messages in app being ported from Carbon (From: Kurt Bigler via Cocoa-dev <email@hidden>)
 >Re: Cocoa window messages in app being ported from Carbon (From: Rob Petrovec via Cocoa-dev <email@hidden>)
 >Re: Cocoa window messages in app being ported from Carbon (From: Uli Kusterer via Cocoa-dev <email@hidden>)
 >Re: Cocoa window messages in app being ported from Carbon (From: Rob Petrovec via Cocoa-dev <email@hidden>)
 >Re: Cocoa window messages in app being ported from Carbon (From: Kurt Bigler via Cocoa-dev <email@hidden>)

  • Prev by Date: Re: Cocoa window messages in app being ported from Carbon
  • Next by Date: Re: Cocoa window messages in app being ported from Carbon
  • Previous by thread: Re: Cocoa window messages in app being ported from Carbon
  • Next by thread: Re: Cocoa window messages in app being ported from Carbon
  • Index(es):
    • Date
    • Thread