Re: Document being reopened on launch during modal dialog
On 9 May 2014, at 10:26 am, Greg Parker wrote: > Ordinary -performSelector: retains nothing. Other asynchronous variants like > -performSelectorOnMainThread:… and -performSelector:…waitUntilDone:NO retain > the receiver and the arguments. Actually I guess I used that as a shorthand for -performSelector:withObject:afterDelay: since we were talking about a delayed perform which seems to be held in a queue managed by the run loop. --Graham ___ 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
Re: Document being reopened on launch during modal dialog
On May 7, 2014, at 6:11 PM, Graham Cox wrote: > On 8 May 2014, at 10:39 am, Kyle Sluder wrote: >> Wait, why do you suspect this? Unless I missed something, there’s no >> guarantee, ARC or not, that a receiver will survive through a method >> invocation. > > How else could it work? -performSelector must hang on to the receiver at > least until the method invocation, so any release must come afterwards, or an > autorelease beforehand which means the release itself will be afterwards. If > it was otherwise -performSelector would be crashing continually, which is not > the behaviour observed. Ordinary -performSelector: retains nothing. Other asynchronous variants like -performSelectorOnMainThread:… and -performSelector:…waitUntilDone:NO retain the receiver and the arguments. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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
Re: Document being reopened on launch during modal dialog
On 8 May 2014, at 10:39 am, Kyle Sluder wrote: > Wait, why do you suspect this? Unless I missed something, there’s no > guarantee, ARC or not, that a receiver will survive through a method > invocation. How else could it work? -performSelector must hang on to the receiver at least until the method invocation, so any release must come afterwards, or an autorelease beforehand which means the release itself will be afterwards. If it was otherwise -performSelector would be crashing continually, which is not the behaviour observed. --Graham ___ 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
Re: Document being reopened on launch during modal dialog
> On May 7, 2014, at 5:07 PM, Quincey Morris > wrote: > > However, it’s probably safe for a different reason. ‘performSelector’ should > retain its receiver Wait, why do you suspect this? Unless I missed something, there’s no guarantee, ARC or not, that a receiver will survive through a method invocation. --Kyle Sluder ___ 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
Re: Document being reopened on launch during modal dialog
On 8 May 2014, at 8:08 am, Mills, Steve wrote: > Is this all safe and legal, releasing self right before it returns to > whatever called it? I believe so, I've done this rarely but occasionally, and it's OK, though if you forget you've done this and later change the calling behaviour in such a way that you assume the object is still there on return from -runDlog it will crash. If you want to be safer, you could use -autorelease instead, which will allow it to live a little longer, until the call stack to this point has unwound and returned to the main loop. There are probably also better ways to set this up in general, such that the runner object is automatically disposed when it's done its job - for example using a block? I've just woken up, so off the top of my head I'm not ready to pinpoint the best approach. --Graham ___ 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
Re: Document being reopened on launch during modal dialog
On May 7, 2014, at 15:08 , Mills, Steve wrote: > Is this all safe and legal, releasing self right before it returns to > whatever called it? I believe it’s safe in manual RR, though you could perhaps do ‘[self autorelease]’ if you feel uncertain. I’m not sure it’d be safe under ARC (that is, doing something that could cause ‘self’ to be deallocated), because ARC might have epilogue code at the end of the scope, and that *might* refer to self. However, it’s probably safe for a different reason. ‘performSelector’ should retain its receiver, and presumably won’t release it until after the performed method returns, so your ‘[self release]’ presumably won’t actually result in deallocation. ___ 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
Re: Document being reopened on launch during modal dialog
On May 6, 2014, at 19:05:22, Graham Cox wrote:
> The compromise we've adopted is to let all the documents open as normal
> *then* show the dialog if necessary on top of them. That avoids the need to
> capture the 'open' URLs, but it's only OK if you can accept the documents
> being there - in our case we can. Doing this is fairly simple though - just
> invoke the dialog opening method after a short delay (1 second in our case) -
> it's enough to ensure it happens after all doc opening has completed, since
> the true main event loop runs normally, opens the documents, then processes
> any pending 'perform after delay' stuff.
I got something working and just wanted to run it by y'all. When the
cross-platform init code gets an error, I call a cross-platform function. The
Mac build of this function allocates an NSObject subclass and tells it to
execute later in the main run loop like so:
RunPlogueModalsInMainEventLoop* runner =
[[RunPlogueModalsInMainEventLoop alloc]
initForProblem:PlogueProblem::kEngineFailed error:errCode];
[runner performSelectorOnMainThread:@selector(runDlog)
withObject:runner waitUntilDone:NO modes:[NSArray
arrayWithObjects:NSDefaultRunLoopMode, nil]];
That object's runDlog method then runs our cross-platform dlog and releases the
Obj-C object (self):
-(void) runDlog
{
// Simplified for clarity:
fcdlg::PlogueEngineFailErrordlg(NULLP, self->error);
dlg.DoModal();
// We're all done with this allocated object:
[self release];
}
Is this all safe and legal, releasing self right before it returns to whatever
called it?
--
Steve Mills
office: 952-818-3871
home: 952-401-6255
___
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
Re: Document being reopened on launch during modal dialog
On 7 May 2014, at 5:41 am, Quincey Morris wrote: > On May 6, 2014, at 12:28 , Lee Ann Rucker wrote: > >> This may be obvious, but did you try moving it all to >> applicationDidFinishLaunching: instead? > > IIUC, Steve’s point was that it won’t help in this case, because state > restoration is initiated before applicationDidFinishLaunching:, and he’s > actually trying to defer state restoration, of documents at least, until > after the modal dialog is dismissed. FWIW, showing a modal dialog during app launch has always been awkward and difficult - documents will open "behind" the dialog unless you go out of your way to prevent it, no matter at what point you invoke the dialog, because the modal loop ends up running an event loop which processes the 'open' events, etc. This can bypass any setup you do in will/finish launching, which runs after the modal loop ends (running modelessly might help with that). You'll probably have to resort to setting flags in your delegate when you show the dialog and use those flags to short-circuit document opening. If the dialog is then cancelled or dismissed, if your app wants to go ahead and open the documents it would have done, you'll have to arrange some mechanism to capture the 'open' events (or at least the document URLs they refer to) and handle them later. It's a huge mess, so basically it comes down to being unsupported. The compromise we've adopted is to let all the documents open as normal *then* show the dialog if necessary on top of them. That avoids the need to capture the 'open' URLs, but it's only OK if you can accept the documents being there - in our case we can. Doing this is fairly simple though - just invoke the dialog opening method after a short delay (1 second in our case) - it's enough to ensure it happens after all doc opening has completed, since the true main event loop runs normally, opens the documents, then processes any pending 'perform after delay' stuff. --Graham ___ 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
Re: Document being reopened on launch during modal dialog
On May 6, 2014, at 12:28 , Lee Ann Rucker wrote: > This may be obvious, but did you try moving it all to > applicationDidFinishLaunching: instead? IIUC, Steve’s point was that it won’t help in this case, because state restoration is initiated before applicationDidFinishLaunching:, and he’s actually trying to defer state restoration, of documents at least, until after the modal dialog is dismissed. ___ 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
Re: Document being reopened on launch during modal dialog
This may be obvious, but did you try moving it all to applicationDidFinishLaunching: instead? We used to have alerts in willFinish too, but now we have comments saying not to do that instead :) On May 6, 2014, at 11:23 AM, Mills, Steve wrote: > I'm looking at a crash log for our app that shows our app is initting. During > init ([NSApplication finishLaunching]) we discover a problem and put up a > modal dialog using [NSApplication runModalForWindow:]. During this modal run > loop, something has decided that it would be a great time to handle the > reopen event, so [NSDocumentController > reopenDocumentForURL:withContentsOfURL:display:completionHandler:] is called > and we open a document while the modal dialog is up, and before we've totally > finished handling [NSApplication finishLaunching]. > > Why would reopen choose to be handled during a modal dialog loop? How can we > prevent this poor design choice from happening? > > -- > Steve Mills > office: 952-818-3871 > home: 952-401-6255 > > > ___ > > 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://urldefense.proofpoint.com/v1/url?u=https://lists.apple.com/mailman/options/cocoa-dev/lrucker%2540vmware.com&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0A&m=5hE6RPo7b8GdoEomoXXIy6%2BmbRDzf%2BzEt%2FQH6IBflY8%3D%0A&s=51568acfd995c5fc420799da6c8d5fc8704e29066c2d20f039e7d8ef7ab57d0a > > This email sent to lruc...@vmware.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
Re: Document being reopened on launch during modal dialog
On May 6, 2014, at 11:55 , Mills, Steve wrote: > We're in [FinaleAppDelegate applicationWillFinishLaunching:] (like you > mentioned later), which is where we call our cross-platform InitApp function > to load things up, set up audio, etc. The audio engine has discovered a > sample rate mismatch and is telling the user about it via modal dialog. I see. But it seems unreasonable to expect that the app won’t finish launching regardless of the modal dialog. (It may even be *necessary* for it to finish launching in order for the modal dialog to work.) So it comes down to a question of a technical violation of runModalForWindow’s event loop blocking, keeping in mind that state restoration likely isn’t triggered by an event at all. Given that a sample rate mismatch sounds like a global condition, I think the “theoretically” correct solution is to change your document’s behavior so that it can exist under the mismatch condition without getting messed up (and perhaps also without fully functionality). However, I don’t imagine you’d contemplate doing that, so I’d suggest instead that you simply override '[NSDocumentController reopenDocumentForURL:…]’ and put its parameters on a queue so that you can re-issue the request from ‘applicationDidFinishLaunching:’. ___ 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
Re: Document being reopened on launch during modal dialog
On 2014 May 06, at 11:23, Mills, Steve wrote: > How can we prevent this poor design choice from happening? How about: Subclass NSDocumentController and override -[NSDocumentController reopenDocumentForURL:withContentsOfURL:display:completionHandler:]. I think that, to get your subclass to to be used by the app, all you need do is instantiate one in the main nib. It looks like that’s all I’ve done, and it works for me. If it doesn’t work for you, let us know and I’ll check my code more carefully. That being said, as Kyle and Quincey have noted, you might still have trouble with that “early" modal dialog. You may need to do that override *and* delay displaying your modal dialog. ___ 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
Re: Document being reopened on launch during modal dialog
On Tue, May 6, 2014, at 11:55 AM, Mills, Steve wrote: > > No. What I mean is that finishLaunching is still being executed. We're in > [FinaleAppDelegate applicationWillFinishLaunching:] (like you mentioned > later), which is where we call our cross-platform InitApp function to > load things up, set up audio, etc. The audio engine has discovered a > sample rate mismatch and is telling the user about it via modal dialog. There have been a few cases on this list where the only resolution has been "-applicationWillFinishLaunching: is too early to start doing things." Have you tried moving your InitApp call to -applicationDidFinishLaunching:? --Kyle Sluder ___ 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
Re: Document being reopened on launch during modal dialog
On May 6, 2014, at 13:44:42, Quincey Morris wrote: > On May 6, 2014, at 11:23 , Mills, Steve wrote: > >> I'm looking at a crash log for our app that shows our app is initting. >> During init ([NSApplication finishLaunching]) we discover a problem and put >> up a modal dialog using [NSApplication runModalForWindow:]. During this >> modal run loop, something has decided that it would be a great time to >> handle the reopen event, so [NSDocumentController >> reopenDocumentForURL:withContentsOfURL:display:completionHandler:] is called >> and we open a document while the modal dialog is up, and before we've >> totally finished handling [NSApplication finishLaunching]. > > It sounds like you’re Doing It Wrong™. Well, sorta j/k, but seriously you’re > overriding ‘finishLaunching’? No. What I mean is that finishLaunching is still being executed. We're in [FinaleAppDelegate applicationWillFinishLaunching:] (like you mentioned later), which is where we call our cross-platform InitApp function to load things up, set up audio, etc. The audio engine has discovered a sample rate mismatch and is telling the user about it via modal dialog. -- Steve Mills office: 952-818-3871 home: 952-401-6255 ___ 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
Re: Document being reopened on launch during modal dialog
On May 6, 2014, at 11:23 , Mills, Steve wrote: > I'm looking at a crash log for our app that shows our app is initting. During > init ([NSApplication finishLaunching]) we discover a problem and put up a > modal dialog using [NSApplication runModalForWindow:]. During this modal run > loop, something has decided that it would be a great time to handle the > reopen event, so [NSDocumentController > reopenDocumentForURL:withContentsOfURL:display:completionHandler:] is called > and we open a document while the modal dialog is up, and before we've totally > finished handling [NSApplication finishLaunching]. It sounds like you’re Doing It Wrong™. Well, sorta j/k, but seriously you’re overriding ‘finishLaunching’? From the NSApplicationDelegate protocol documentation: > "applicationDidFinishLaunching: > > "Delegates can implement this method to perform further initialization. This > method is called after the application’s main run loop has been started but > before it has processed any events. If the application was launched by the > user opening a file, the delegate’s application:openFile: method is called > before this method. If you want to perform initialization before any files > are opened, implement the applicationWillFinishLaunching: method in your > delegate, which is called before application:openFile:.)” So documents may be opened between the issuing of the two notifications (wiil/didFinishLaunching). Both of those notifications, I would assume, are posted in ‘finishLaunching’, so your concept of “totally finished handling [NSApplication finishLaunching]” sounds flawed. In particular, putting up a modal dialog before invoking [super finishLaunching] — if that’s what you do — sounds like a bad idea. Why aren’t you doing the initialization in the delegate methods? ___ 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
