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: Uli Kusterer via Cocoa-dev <email@hidden>
- Date: Sat, 31 Aug 2019 02:17:31 +0200
> On 12. Aug 2019, at 05:26, Kurt Bigler via Cocoa-dev
> <email@hidden> wrote:
>
> 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.
That sounds like it will cause problems. I may have mis-remembered, but one of
the event loops is compatible with the others. So maybe what we did during our
bring-up phase back then was just call RunApplicationEventLoop(). Not sure if
we called it from main() or if calling it from applicationDidFinishLaunching
worked. It's been too long since I ported a Carbon app to Cocoa.
But single-dispatching events from a Timer means that half your events get
processed by AppKit's -sendEvent:, and half by ReceiveNextEvent(). That can't
go well.
>> 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!
Also one tip: You may have to call NSApplicationLoad() at some point, or create
an NSImage to initialize certain subsystems of Cocoa in an otherwise Carbon app
(i.e. when you're not letting NSApplicationMain run the event loop). I think
the NSImage thing may have been for some window activation issue too (I know
that sounds weird because NSImage and NSWindow don't seem related, I just
remember being told that at WWDC once, and it helped us for ... something)
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
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