Re: NSAlert boxes ...

Sandor Szatmari

The MRR rules are straight forward and deviating from them because the runloop may retain the alert is asking for trouble in my opinion.  There is no harm in taking ownership of the alert and releasing/autoreleasing it.  I would argue that doing so ensures that any changes in SDK/runtime behavior don’t adversely affect your product.  


On Feb 16, 2020, at 19:26, Peter Hudson via Groups.Io <Peter.hudson@...> wrote:

Thanks Graham and Alex. 
I had reached the same sort of conclusions - but could not find any corroborative info anywhere ....

On 16 Feb 2020, at 23:59, Graham Cox <graham@...> wrote:

Normal rules require that you either autorelease it or release it when you’re done (assuming manual MM of course).

If no autorelease or release was required, then that would be an exception to normal rules, and NSAlert is not documented as an exception to those rules. However, the alert can stay on screen for a long time, and the event loop is running, albeit modally. That means that autorelease pools are getting drained. So *something* must be keeping the alert alive until the user dismisses it.


On 17 Feb 2020, at 10:49 am, Alex Zavatone via Groups.Io <zav@...> wrote:

Sorry, A bit groggy here.  If my previous assumption that autorelease isn’t needed is incorrect, then it might be  that the instance will be retained until the reference to it is cleared or the enclosing object is deallocated.

Join { to automatically receive all group messages.