> On 12. Aug 2019, at 05:26, Kurt Bigler via Cocoa-dev > <cocoa-dev@lists.apple.com> wrote: > > On 8/10/19 2:38:00 PM, Uli Kusterer wrote: >>> On 10. Aug 2019, at 23:02, Kurt Bigler <kkbli...@breathsense.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
