On 23.08.2016 at 01:17 Graham Cox wrote:
>> On 23 Aug 2016, at 1:46 AM, Andreas Falkenhahn <andr...@falkenhahn.com> >> 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:andr...@falkenhahn.com _______________________________________________ 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
