On 9 May 2014, at 10:26 am, Greg Parker gpar...@apple.com 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
On May 7, 2014, at 6:11 PM, Graham Cox graham@bigpond.com wrote:
On 8 May 2014, at 10:39 am, Kyle Sluder k...@ksluder.com 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
On May 6, 2014, at 19:05:22, Graham Cox graham@bigpond.com 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
On May 7, 2014, at 15:08 , Mills, Steve smi...@makemusic.com 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
On 8 May 2014, at 8:08 am, Mills, Steve smi...@makemusic.com 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
On May 7, 2014, at 5:07 PM, Quincey Morris
quinceymor...@rivergatesoftware.com 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
On 8 May 2014, at 10:39 am, Kyle Sluder k...@ksluder.com 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
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
On May 6, 2014, at 11:23 , Mills, Steve smi...@makemusic.com 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
On May 6, 2014, at 13:44:42, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On May 6, 2014, at 11:23 , Mills, Steve smi...@makemusic.com wrote:
I'm looking at a crash log for our app that shows our app is initting.
During init ([NSApplication finishLaunching]) we discover a
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
On 2014 May 06, at 11:23, Mills, Steve smi...@makemusic.com 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
On May 6, 2014, at 11:55 , Mills, Steve smi...@makemusic.com 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
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
On May 6, 2014, at 12:28 , Lee Ann Rucker lruc...@vmware.com 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
On 7 May 2014, at 5:41 am, Quincey Morris quinceymor...@rivergatesoftware.com
wrote:
On May 6, 2014, at 12:28 , Lee Ann Rucker lruc...@vmware.com wrote:
This may be obvious, but did you try moving it all to
applicationDidFinishLaunching: instead?
IIUC, Steve’s point was that it won’t
16 matches
Mail list logo
