Post by Graham Cox Post by Andreas Falkenhahn
It is unusual in the way that it's not calling NSApplicationMain() but tries
to imitate what NSApplicationMain() does. Here goes the code that is executed
There’s your problem.
You’re not running a proper NSRunLoop, so the alert panel is going
to be non-operational. When a modal alert is shown, the run loop is
set to a run mode that reflects this, which changes the way events
are routed and processed. Modal panels are really an illusion that
the application creates by managing its NSRunLoop in this way.
You are going to have to fix your architecture to run the app in a far more conventional way.
I know what you said about a cross-platform model forcing your
hand, but I don’t believe that your solution is the right one. I
believe you can run the app in a standard way and still support this
model. I know this because I had to do exactly the same thing when
Mac OS X first came out, to adapt my app framework for the classic
Mac OS (“MacZoop”) to run on OS X. That framework had a
WaitNextEvent() style architecture, but with care I was able to
adapt it to the modern approach without breaking that model, but
still being something that played nice with preemptive mutitasking,
non-centralized event despatch, and so on. Of course that was 15
years ago, and the details are now hazy, but the essence of it was
WaitNextEvent is not something you poll, but something that goes to
sleep until there’s something for your app to do. From the client’s
perspective, there’s no difference!
I suggest you reinstate a standard runloop within NSApplication,
stop playing games with it, and simply use its
-nextEventMacthingMask: method to stand in for WaitNextEvent(). All
your various problems will be solved at once.
I really can't use NSApplicationMain() because AFAICS it also expects
to load a NIB file from the app bundle which simply doesn't exist for
my app because I'm not using Xcode at all and everything is set up
programmatically. Please understand that people interested in cross-
platform development tend to keep all dependencies on proprietary
technologies like NIB and proprietary programs like Xcode to an absolute
minimum if possible. Just give me a proper makefile instead and I'm
And it absolutely is possible to create apps without going the orthodox
route using NIBs and NSApplicationMain(). Just look at the Cocoa backends
of popular cross-platform toolkits like wxWidgets, SDL, GLFW... AFAICS,
none of them ever calls into NSApplicationMain(). Instead, they all seem
to use custom app set up code and custom event loops.
I'd just wish that Apple would provide some more information to developers
who wish to avoid the conventional way because currently there's a lot
of guesswork involved and of course there's always the risk that apps
using such custom code won't be compatible with future OS X versions.
That's why some official documentation on alternatives to NSApplicationMain()
would be really nice because then they would be really safe to use.
That being said, I've now figured out what was the cause of the hang
on 10.6. Calling [NSApp stop] was the culprit here. Instead of [NSApp run]
I just have to call [NSApp finishLaunching] and everything is good.
Post by Graham Cox
Or use Carbon, not Cocoa, but good luck with that.
I have been using Carbon for the last 12 years and I'd love to be able
to continue using it because I prefer clean, old school C APIs but, alas,
we all know that it was cancelled quite unexpectedly. In fact, when I started
to write a Carbon backend some 12 years ago the official word was still that
one could use whatever one preferred, Carbon or Cocoa. As a C programmer I
took to Carbon of course only to learn after a few months that there would
be no 64-bit support for Carbon, but that's another story I guess. I still
maintain the Carbon backend for the PowerPC branch of my app, though ;)
Andreas Falkenhahn mailto:***@falkenhahn.com
Cocoa-dev mailing list (Cocoaemail@example.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:
This email sent to ***@ml-in