Re: NSAlert::runModal doesn't work on 10.6
Re: NSAlert::runModal doesn't work on 10.6
- Subject: Re: NSAlert::runModal doesn't work on 10.6
- From: Andreas Falkenhahn <email@hidden>
- Date: Tue, 23 Aug 2016 16:52:43 +0200
On 23.08.2016 at 01:17 Graham Cox wrote:
>> On 23 Aug 2016, at 1:46 AM, Andreas Falkenhahn <email@hidden> wrote:
>> 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
>> to set up the NSApp:
> 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
> to turn the thinking about fetching events on its head:
> 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
happy.
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.
> 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 ;)
--
Best regards,
Andreas Falkenhahn mailto:email@hidden
_______________________________________________
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