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.

  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 (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

Reply via email to