On May 22, 2014, at 12:24 PM, Jens Alfke wrote:
>
> On May 22, 2014, at 8:54 AM, edward taffel wrote:
>
>> i find no mention of thread safety in the NSOpenPanel doc, but the doc
>> mentions ‘Open panels are drawn in a separate process by the powerbox’:
>> perhaps this is the reason.
>
> Th
On May 22, 2014, at 8:54 AM, edward taffel wrote:
> i find no mention of thread safety in the NSOpenPanel doc, but the doc
> mentions ‘Open panels are drawn in a separate process by the powerbox’:
> perhaps this is the reason.
That’s done because the Open panel itself can’t be bound by the li
On 22 May 2014, at 10:54 AM, edward taffel wrote:
> i find no mention of thread safety in the NSOpenPanel doc, but the doc
> mentions ‘Open panels are drawn in a separate process by the powerbox’:
> perhaps this is the reason.
This is one of those rules so universal in Apple APIs that it is ne
On May 22, 2014, at 11:41 AM, Jens Alfke wrote:
>
> On May 22, 2014, at 8:29 AM, edward taffel wrote:
>
>> this i have remedied. however, given the scenario where a url has vanished,
>> i first show an NSAlert & then an NSOpenPanel to offer relink. NSOpenPanel
>> causes no such background t
On May 22, 2014, at 8:29 AM, edward taffel wrote:
> this i have remedied. however, given the scenario where a url has vanished, i
> first show an NSAlert & then an NSOpenPanel to offer relink. NSOpenPanel
> causes no such background thread issue: do the two have variant thread
> safety? or is
opening an NSAlert while scanning an autosaved document now engenders the
following log item:
NSAlert is being used from a background thread, which is not safe. This is
probably going to crash sometimes. Break on void
_NSAlertWarnUnsafeBackgroundThreadUsage() to debug. This will be logged onl
