Hi,
Does anyone know why Apple recommends applications instead of scripting additions? Is there an advantage?
Thanks,
Hi,
Scripting Additions are based on outdated Carbon technology
(Faceless) scriptable applications like System Events use state of the art Cocoa scripting
Hi Stefan,
Oh I see, so you can only make carbon scripting additions.
Thanks,
Yes, and the workflow is horribly complicated
You know, it seems like it’s more complicated because of the change, it’s actually easier in the end. I’ve seen how much this system has improved.
Thanks a lot,
Cocoa scripting could be pretty tricky, but compared with Carbon scripting it’s child’s play
Yeah, and it looks nicer, also. Just last night, I was thinking about making an egg timer with xCode. I made one with the old Interface Builder. It might be a good restarter in xCode and I need a good one I can modify.
THanks,
I’m procastinating. 
It can be further improved with Stefan’s progressbar.
local eggBoilingTime, notDone
set eggBoilingTime to 4.5
set notDone to true
repeat while notDone
try
set eggBoilingTime to text returned of (display dialog "Set the time for the eggs to boil.." with title "Egg Timer" default answer eggBoilingTime buttons {"Cancel", "Start."} default button 2) as number
set notDone to false
on error e number n
if n = -128 then
error number -128
end if
end try
end repeat
display dialog "Really boil the Eggs for " & eggBoilingTime & " Minutes?" with title "Egg Timer"
set eggBoilingSeconds to eggBoilingTime * 60
do shell script "sleep " & eggBoilingSeconds
tell current application
activate
display dialog "Eggs Ready" with title "Egg Timer" buttons {"Ok"} default button 1
end tell
I still wonder, if AsObjC is something StefanK starts off a procject with, or if he dives right into cocoa, I wonder about the AsObjC step, if that is something to step over, or not. I could really need some expert advice, whether to skip it or not. 
Hi McUsr,
You need a delay in there so the user can quit. I accidentally set it to 10 minutes (waiting …).
I never use pure AppleScriptObjC applications.
If I need inter-application communication, I’m using AppleScriptObjC scripts as ObjC classes.
Cooca is always the first step to start with
It was a spelling error, so I guess you got a way with 4.5 minutes. I have updated it with a confirmation dialog, giving you a chance to bail out. You’ll have to kill a do shell script command from activity monitor to stop it, once it has started to run, (or from the commandline with the kill utility.)
I never ment pure, but I read you as you wouldn’t invest time in AsObjC before you need ipc through AsObjC.
Thanks for the advice.
Just joking. I know how to get out of an app that won’t quit.
The big advantage is that they’re not scripting additions 
Scripting additions were a great hack – in those days the theoretical maximum number of Apple events you could send was 60/second – but they had frightening security implications.
If you know Cocoa, there’s really very little to learn to use ASObjC. Just some simple new syntax, a couple of conversion issues, and the mechanics of adding it to a project.
Unlike Stefan, I sometimes write straight ASObjC apps – often quick-and-dirty stuff, or where I don’t need an interface and I don’t want the overhead of fussing with Xcode.
And, you know, it’s easier to make apps.
Advantages is with an application is that it launches on demand and you have one application loaded and share with every instance of AppleScript. Drawback is that when the application is already busy or hangs all the scripts will suffer that sends events to this application too. Scripting addition are loaded for every instance of AppleScript which makes loading scripts slow down as the number of scripting additions increases. The advantage is that every instance of AppleScript loads the osax separately, so they don’t interfere with each other. Not to forget that AppleScript is single threaded including scripting additions but using applications you can use (limited) multi threading.
The reason why Apple recommends applications is because it’s cocoa. The computers are very fast nowadays and the speed difference between Carbon and Cocoa isn’t really an issue anymore. Carbon is faster but most Objective-C developers think about C as an more difficult language. Carbon was also a lot more open while Cocoa is a lot more restricted. At last, Carbon’s disadvantage is that it had an busy-wait method for event handling, this resulted that a delay command in AppleScript froze the machine in Mac OS.
The third way, how I use ASObjC mostly is writing the entire application in Objective-C and only one class in ASObjC for ipc for each application I’m using. So I start with an Cocoa/Objective project and add the AppleScriptObjC framework to the project. But mainly because I knew Objective-C before I started with ASObjC otherwise I would probably write complete ASObjC apps like Shane.
FWIW, ASObjC Runner does most of its processing on background threads so it can respond to multiple scripts simultaneously.
In terms of implementing AS commands I’m not sure it ever really was a serious issue, given the other overheads.
There’s a reason for that
My problem is, is that I don’t know if the advantages of using AsObjC outweighs the overhead of learning it.
That is something I only can know hindsightly, but I’ll give it a spin when time permits, or try to make a comparative study as I go along. Finding the sweet-spot for it, beyond ipc, and if it suits me. I am reluctant to write the quick and dirty stuff, in C and shell with a wrapper of AppleScript if necessary
This was a thread that grew of interest, while I was pondering. Just let me shoot in, in the end, that I don’t think C is any more difficult by itself than Objective-C, but its usage, being a procedural language and all, makes it more complicated, when you write bigger programs. The abstraction level, is what you invent yourself, and that makes up for a lot of overhead compared to Objective-C with its Cocoa framework. (There is some help with CoreFoundation, but just so much.)
Edit
Finally:
Sometihg that worries me a bit, is whether Apple will port the Carbon Example Projects to Cocoa, or not, there are some Carbon projects that are pretty much indispensible, when there are no Cocoa Counterpart.
The new worries, or stuff for wild speculation, is the the new Javascript-Cocoa bridge, released a couple of days ago, could this be part of a bigger shift?
I always forget or underestimate the benefit of AppleScriptObJ Explorer.