HI, The thing is the code is being called Asynchronously anyway, I think the point was that this code assumes that that the delegate needs to run on the Main Thread, which in my mind is just as bad as

Yes, I’m only using one version of XCode, I’ve tried all the usual things, like restarting, cleaning, quitting etc. Cheers Dave

For my own purposes, this looks like a good solution to a problem. I've never been much of a user of AppleScript, though, so I'm not sure how one creates such a lower-level app to be called from the

That’s one of the cool things about it. Nothing special about the lower level (main) app. It is simply a standard app. You can either do the installation yourself there, have the top level installer

OK, that is useful. What I'm trying to implement is a system to move files around into correct folders without troubling the user about finding the correct places in the file system. So the

John; I suspect you are putting more into the scripting idea than is really needed. The only thing I use AppleScript for is to launch the installer application. That (standard Mac) application is

Thanks, that's very helpful. I will try it out when I get the time (my day job is getting in the way of my programming these days). John Jack Brindle wrote: -- John Brownie SIL-PNG, Ukarumpa, Eastern

Sounds like this would be a good approach for me. Sounds like I could build a helper app, make it available in my main app's bundle, and call it with arguments to install/uninstall and load/unload

Any class that supports a delegate inherently understands its own threading behaviour, and thus can (should) articulate the policy under which it will call its delegates. It looks like your code uses

Just to follow up, it all works nicely. I've done it in Swift rather than Objective-C. The string handling is a little messy, as I need to get the quoted form of each argument (they're all

Hi, No, but I looked at it to see how to setup Game Center, I have a similar Class but its uses the Turn Based Classes/Delegates. The thing is, in my case, it actually doesn’t matter if its run on

For the archive, "UI" is the largest group of API that can't be backgrounded, and the easiest to explain. There are many other such interfaces. The hard (both inflexible and difficult) rule is that

(Belated) thankyou to the various very helpful replies I had to this question of mine. I think I understand it now, and can see what is not going to work with my setup. I still find the behaviour a

I have a general question about memory management of a panel shown as a sheet. As a general design pattern, I often have a class method that returns a new instance of a NSWindowController subclass

Yes to the release, but not “self”. The receiver for “beginSheet:completionHandler:” is the window on which the sheet is displayed. It (or perhaps the NSApplication object on its behalf) must

OK, this agrees with my own reasoning - I retain the controller prior to the beginSheet, and release it in the completion block. But there’s no other funny business - no NSWindow subclass or

If I’m reading the code correctly, the window is deterministically kept alive by the block (which captures “self” strongly). The block is kept alive by whatever object is going to invoke the

I meant “window controller” of course.

There’s still some “magic” about blocks I’m not altogethr clear about. When are blocks, as an actual object, created? At what point do they retain their references? I ask because I wonder if

Hmm. I just realized I forgot this was MM not ARC. In that case, I don’t know if the block retains “self” automatically at all. It shouldn’t, since it’s MR, but it’s possible that it