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
-per
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? -performSele
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
> 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 metho
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
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,
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
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
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
ac
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 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 mismatc
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
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, se
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 [NSApplica
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, some
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
16 matches
Mail list logo
