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: Kurt Bigler via Cocoa-dev <email@hidden>
- Date: Sun, 11 Aug 2019 20:26:38 -0700
On 8/10/19 2:38:00 PM, Uli Kusterer wrote:
On 10. Aug 2019, at 23:02, Kurt Bigler <email@hidden> wrote:
Currently if I call NSApplicationMain instead of my regular Carbon event loop
(which is based on ReceiveNextEvent), NSApplicationMain returns immediately. I
don't call NSApplicationMain immedately because there is scads of
initialization that I do without relation to incoming events.
NSApplicationMain looks at your Info.plist to decide which Cocoa NIB to load
at startup and what your NSPrincipalClass is (usually NSApplication). If you
haven't set up your app as a proper Cocoa app, NSApplicationMain will be
unhappy and won't work. Every time I've ported a Carbon app to Cocoa so far, I
basically moved the main() function's contents (except the call to
RunApplicationEventLoop()) into applicationDidFinishLaunching: etc. in an app
delegate. Then it usually worked as before.
I've reconfigured the info.plist and the relevant code is now inside
applicationDidFinishLaunching as you suggested. However the other area you
point out is probably a source of issues.
My Carbon code is now not getting many events. It was not getting any events
until I arrange to call the Carbon event loop body (single event) from a timer I
put in the app delegate. See the next bit.
ReceiveNextEvent() seems a bit of an odd choice.
Yes well it is what I put in there to move my pre-Carbon code forward when OSX
came along, or some time after, when WaitNextEvent stopped being supported or
did not work with some other event stuff I needed. I might have gotten it by
upgrading my TCL-based app from information in the Power Plant code.
And basically when I carbonized I did the very minimum. It was already too
expensive for the client. I did not use any "new" Carbon, only the oldest
Carbon, until some specific need showed up and I had to retrofit something new
in there. So, specifically, I never created event handlers except for events I
was otherwise simply not going to get. The rest was done the old Carbon way
with WaitNextEvent-based logic replace with ReceiveNextEvent, for whatever
reason I chose that.
And specifically I have never used HI Anything. I simply did not have budget to
learn the new stuff when I needed to Carbonize. So maybe this is why I'm
involved in this current set of issues around not getting some "carbon" events
(if not literally CarbonEvents as I recall the newer stuff is called.
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.
...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? Thanks for advice on that. I realize the app is way not up
to speed on some really old things, and also that I hope not to spend weeks
learning Carbon Events in order to get the port to Cocoa going.
In general, you want RunApplicationEventLoop() and timers,
performSelector:afterDelay:0.0 or threads to get processing time reliably for
other things during the event loop.
Yes, indeed. I don't know how far I am from RunApplicationEventLoop(), nor does
it make sense offhand how I could both do that and use NSApplicationMain, except
for modal situations, or maybe dragging.
Thanks again for any reflections on all this!
-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