• 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: Mon, 12 Aug 2019 13:06:34 -0700

On 8/11/19 8:26:38 PM, Kurt Bigler via Cocoa-dev wrote:
So now I'm getting osEvt, mouseDown, and updateEvt, but no activateEvt, and so the mouseDown only tries to activate each time.  I can probably workaround that by accepting the first click.

Adding a Carbon window event handler seems to be the way.  I added a handler for

        kEventClassWindow/kEventWindowActivated and
        kEventClassWindow/kEventWindowDeactivated

Through that I am getting activate events. So I no longer have to accept activate clicks to get mouseDowns. And the whole need for calling the Carbon event handling from a Cocoa timer went away, and with it the dropped mouse ups.

...Yes, doing that yields an app that is closer to working than what I've seen yet.  Mouse ups are sometimes being dropped though.  And while Carbon portions are working much better, Cocoa windows are now non-interactive, no longer getting any clicks, and with the close/minimize/zoom buttons dimmed.

But with activateEvt being the culprit, maybe I'm in the normal territory for Carbon+Cocoa scenario?

But do you think there is something better I can do than call the Carbon event handler on a timer?

Taken care of by the above.

Cocoa mouseDowns were still being eaten. Then I discovered that without realizing it, invocation of my Carbon event loop was part of the code I had added to applicationDidFinishLaunching in trying to "clean up" my Carbon/Cocoa hybrid situation. So there was no Cocoa event loop running, and the mouseDown part of my Carbon handler was of the classic polling (via ReceiveNextEvent) variety, which provides no way to filter for events that are Carbon-window only. Thus the Cocoa mouseDowns were getting absorbed, with no practical way (that I found) to re-dispatch them to the Cocoa windows.

Regardless, presumably if I flesh out the Window event handlers on the Carbon side I will see my way through the remaining problems. I'll report back after I work through that.

-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: Uli Kusterer via Cocoa-dev <email@hidden>)
 >Re: 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: Uli Kusterer 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: NSLog displays inconsistent format for NSDate
  • 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