On Aug 27, 2013, at 7:24 AM, Bradley O'Hearne wrote:
> So switching to iOS for a moment, things like location services callbacks,
> NSURLConnection callbacks, animation completion handlers, accelerometer and
> touch events -- all main thread? (I'm pretty sure a few of those aren't main
> thre
On Aug 26, 2013, at 2:05 PM, Kyle Sluder wrote:
> In general, you can assume main-thread (or calling-thread) unless
> otherwise specified. The system frameworks typically aren't
> multithreaded. (They might use worker threads internally, but do their
> best to hide that from you.)
So switching t
On Mon, Aug 26, 2013, at 12:04 PM, Bradley O'Hearne wrote:
> Thanks for the clarification. This actually raises a related point, one
> that I've repeatedly found myself asking in various situations (such as
> this one), in both iOS and Mac dev. Is there some global reference or
> quick way of deter
On Aug 26, 2013, at 11:11 AM, Ken Thomases wrote:
>
> No. Both methods are called on the main thread, so they can't run
> simultaneously.
Ken,
Thanks for the clarification. This actually raises a related point, one that
I've repeatedly found myself asking in various situations (such as this
On Aug 26, 2013, at 12:15 PM, Bradley O'Hearne wrote:
> After accepting the fact that no specific sequence of method invocations can
> be expected, and letting this digest over the weekend, a possible nuance
> suddenly occurred to me: does this essentially mean that in addition to
> either invo
> On Aug 23, 2013, at 7:35, Uli Kusterer wrote:
>> Though I still think it’s safer to NOT rely on this order, and instead
>> perform the initialization in a lazy-loading accessor, so that it is
>> guaranteed the first one who needs the information (and requests it using
>> the accessor) causes
Dang, now my mind switched back into Classic mode and I used kAEOpenApplication
instead of calling it ‘oapp’ as Jens called it. Sorry for the confusion, the
two things are equivalent. Mine’s the constant, Jens’ is the value. Carry on.
On Aug 23, 2013, at 7:35, Uli Kusterer wrote:
> On Aug 22, 2
On Aug 22, 2013, at 18:29, Bradley O'Hearne wrote:
> On Aug 22, 2013, at 9:00 AM, Kyle Sluder wrote:
>> On Aug 22, 2013, at 8:00 AM, Jens Alfke wrote:
>>> On Aug 22, 2013, at 1:34 AM, Uli Kusterer
>>> wrote:
>>>
The notion of one of these being ‘more correct’ than the other is
ridi
On 23/08/2013, at 10:44 AM, Shane Stanley wrote:
> Jens,
>
> Are you sure you're not misremembering?
And he was not...
--
Shane Stanley
'AppleScriptObjC Explored'
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin r
On 23/08/2013, at 10:53 AM, Bradley O'Hearne wrote:
> Just to clarify -- it is broken in that it's behavior doesn't specifically
> instead of doing specifically ?
The actual bug was logged on AppleScript behavior, so excuse the diversion -- I
suspect you can extrapolate. Traditionally the lau
On Aug 22, 2013, at 5:44 PM, Shane Stanley wrote:
> If so, I'd point out that it's broken (as in behaves like 'oapp', aka "run")
> in the current OS, and has been for some time.
Shane,
Just to clarify -- it is broken in that it's behavior doesn't specifically
instead of doing specifically
On 23/08/2013, at 9:36 AM, Jens Alfke wrote:
> Nope. (And not to pull rank, but I was on the AppleEvents/AppleScript team at
> the time we figured this stuff out [1991] and added the seemingly-useless
> ‘oapp’ event in response to developer complaints.)
> Actually I forgot the more significa
On Aug 22, 2013, at 9:00 AM, Kyle Sluder wrote:
> In your example, the difference doesn't matter. If the app is sitting at the
> new doc assistant, or has a default blank document open, it should close that
> assistant or document and open the one requested via URL. Apps have been
> doing thi
On Aug 22, 2013, at 9:00 AM, Kyle Sluder wrote:
> On Aug 22, 2013, at 8:00 AM, Jens Alfke wrote:
>
>>
>> On Aug 22, 2013, at 1:34 AM, Uli Kusterer
>> wrote:
>>
>>> The notion of one of these being ‘more correct’ than the other is
>>> ridiculous. The second case is simply a performance opti
On Aug 22, 2013, at 8:00 AM, Jens Alfke wrote:
>
> On Aug 22, 2013, at 1:34 AM, Uli Kusterer
> wrote:
>
>> The notion of one of these being ‘more correct’ than the other is
>> ridiculous. The second case is simply a performance optimization from the
>> classic MacOS days that was carried ov
On Aug 22, 2013, at 1:34 AM, Uli Kusterer wrote:
> The notion of one of these being ‘more correct’ than the other is ridiculous.
> The second case is simply a performance optimization from the classic MacOS
> days that was carried over to OS X.
Nope. (And not to pull rank, but I was on the Ap
On Aug 22, 2013, at 10:34 AM, Uli Kusterer wrote:
> The notion of one of these being ‘more correct’ than the other is ridiculous.
Maybe ridiculous is a bit too harsh a choice of word, sorry. Let's say I think
that one of them being 'more correct' makes no difference in practice, and is
not sup
On Aug 22, 2013, at 1:08, Jens Alfke wrote:
> Basically it sounds like the bug is that someone is doing (in pseudocode)
> app = app_for_url_scheme(url.scheme)
> launch_app(app)
> send_url_to_app(url)
> instead of the correct way:
> app = app_for_url_scheme(url.scheme)
>
On Aug 20, 2013, at 5:41 PM, Bradley O'Hearne wrote:
> In my case, the URL is custom, configured with launch services and in my
> app's info.plist file. The app is launched by opening a URL with the
> specified protocol from a web browser. It is not being launched any other way
> (such as fro
On Aug 20, 2013, at 1:05 PM, Jens Alfke wrote:
>
> On Aug 20, 2013, at 11:38 AM, Bradley O'Hearne
> wrote:
>
>> 1. Is there any guaranteed invocation order of these methods, or is it
>> completely random? I cannot think of any scenario where you'd want to
>> process the URL launching event
On Aug 20, 2013, at 12:37 PM, Jerry Krinock wrote:
>
> On 2013 Aug 20, at 11:38, Bradley O'Hearne wrote:
>
>> So far, this problem seems isolated to Snow Leopard, I have not seen it on
>> Lion or Mountain Lion. Also, the problem is intermittent [and much more] …
>
> Brad, you probably know
On Aug 20, 2013, at 12:37 PM, Ken Thomases wrote:
> No, you're mistaken. This is not a callback specifically for an app being
> launched to handle a URL. It's a callback to handle a request to open a URL,
> whenever it happens. It is perfectly normal for it to be delivered after an
> app i
On Aug 20, 2013, at 11:38 AM, Bradley O'Hearne
wrote:
> 1. Is there any guaranteed invocation order of these methods, or is it
> completely random? I cannot think of any scenario where you'd want to process
> the URL launching event *after* the callback which signifies app launch
> completio
On 2013 Aug 20, at 11:38, Bradley O'Hearne wrote:
> So far, this problem seems isolated to Snow Leopard, I have not seen it on
> Lion or Mountain Lion. Also, the problem is intermittent [and much more] …
Brad, you probably know more about this problem than anyone in the world today.
For issu
On Aug 20, 2013, at 1:38 PM, Bradley O'Hearne wrote:
> I have a Mac app that is launched via a URL handler that is installed. The
> launch services / configuration setup of the URL handler is fine, app
> launches just as expected. However, I am seeing an intermittent problem where
> the URL han
Hello….
I have a Mac app that is launched via a URL handler that is installed. The
launch services / configuration setup of the URL handler is fine, app launches
just as expected. However, I am seeing an intermittent problem where the URL
handling method:
- (void)handleGetURLEvent:(NSAppleEve
26 matches
Mail list logo
