Hrm, well I’m sure I’ll get around to Xcode 4 someday - I just can’t be bothered downloading it at the moment 
But I’ve read that you can have them both alongside each other. You just run the main installer and tell it to install somewhere other than “/Developer”, say “/Xcode3” (or use Pacifist to do the same thing).
oh? if you’re right about this then that’s the way to procees if you really want easy access to OSX’s gui with AppleScript… I had no idea Xcode 4 would be dropping support, and installed over top of Xcode 3. The new Xcode is quite nice, with lots of apps merged right into Xcode (like IB3, plist editor, etc…) and it’s really quite nice once you get used to the new interface.
For some, installing 2 versions of Xcode side-by-side (probably totalling 10+GB) just to have AppleScript support for nib-coding is worth it, thanks for mentioning this gannett…
But alas, for others, me included, 2 Xcode installs on the system is a bit too bulky for the benefits it offers. My system is too weighed down as is (I’m dragging 4 browsers around) and I’m too weak to be hauling another 4-5 tons around. 
– Aesthir
Well I still haven’t downloaded Xcode 4 yet (given that it’s free again now I don’t have a lot of excuse) but I had a play around to see if I could isolate IB 3. This is everything you need:
Interface Builder 3
- Applications
-
- Interface Builder.app
- Library
-
- Frameworks
-
-
- InterfaceBuilderKit.framework
-
-
- Private Frameworks
-
-
- DevToolsCore.framework
-
-
-
- DevToolsFoundation.framework
-
-
-
- DevToolsInterface.framework
-
-
-
- DevToolsKit.framework
-
-
-
- DevToolsRemoteClient.framework
-
-
-
- DevToolsSupport.framework
-
-
-
- DocSetAccess.framework
-
-
-
- JavaKit.framework
-
-
-
- XDBase.framework
-
- Platforms
-
- MacOSX.platform
It totals just over 100 MB. If you like you can even package it all up into a self-contained app.
FYI to everyone.
I just got 10.7 Lion. “call method” is no longer supported. Neither Automator Runner nor AppleScript Runner know the command. As such my script from post #4 won’t even compile any more. There is a solution though, AppleScript Editor now has the ability to use AppleScriptObjC. The release notes state that applications created this way will work on 10.7 and 10.6.
Yup, the runners no longer include the ASK dictionaries on 10.7 which is kinda annoying. The Editor isn’t really any different from 10.6 though, the use of ASOC is only thanks to a template ASOC app that comes with it (which is buggy). I think it’s pretty dumb, you might as well make your own ASOC app in Xcode.
We’re all entitled to our opinions…
… but that doesn’t follow. Building Cocoa-based apps like that, or with my AppleScriptObjC Explorer, can be a lot simpler than using Xcode if there’s not a lot of UI requirement. There are plenty of cases where even AS droplets could benefit from access to AppleScriptObjC. It’s another option.
People complain hen stuff is taken away, and then complain when stuff is added…
Sorry, not trying to be rude about it. It’s just that when I first read it on the Lion features page I assumed it was proper support for ASOC in AppleScript Editor and any script file but it totally isn’t anything we couldn’t do already on Snow Leopard - it seems wrong to call it a new feature. I also wasn’t expecting to get an error from basic code like this:
on run
quit
end run
on quit
continue quit
end quit
And now that the runners no longer have ASK dictionaries we don’t have any means of making method calls from a script file/bundle. Ah well, time to accept that ASK is obsolete.
[edit] Automator services that use ASK commands don’t work anymore (though they still appear to compile within the editor). Yup, ASK is dead.
Well it is new that you can even compile AS class files in ASE, and the way it handles the bundling is new. But no, it’s not earth-shattering, especially without any logging. (And yes, AppleScriptObjC Explorer 2 works on Snow Leopard as well as Lion, with logging.)
It looks like it.
I know that the major changes in AppleScript in Lion, and the justifications and frustrations associated with it are discussed above. I am trying to decide how I should proceed.
First, a quick summary. A while back, Gannet wrote a great, awesome, progress bar routine that called Automator Runner. In 10.6 and older releases, the code looks like this:
tell application "Automator Runner" to try
set MyBundle to call method "bundleWithPath:" of class "NSBundle" with parameter (POSIX path of (path to me))
-- The MainMenu nib contains just the basic edit and window commands, disabling Automator Runner's Quit and Hide
load nib "MainMenu" in bundle MyBundle
-- Since all our windows are owned by Automator Runner, it's a good idea to activate whenever displaying something
--activate
-- Windows are quickly unloaded if they are not used. Prepare any data for the initial setup of a window before loading the nib.
--set mp3Icon to load image mp3Icon
try
set progIcon to load image progIcon
end try
load nib "ProgressWindow" in bundle MyBundle
tell window "progress"
activate
set title to progTitle
set content of text field "upper" to progText
try
set image of image view "icon" to progIcon
on error errmsg number errnum
--display dialog errmsg & return & return & errnum
end try
set content of progress indicator "bar" to 0
show it
repeat with i from 0 to (estTime * 10)
delay 0.1
[i]etc etc
[/i]
If you look at the same code in Lion 10.7, you get all of this «event appSloaN» junk:
tell application "Automator Runner" to try
set MyBundle to «event appScalM» "bundleWithPath:" given «class of C»:"NSBundle", «class witQ»:(POSIX path of (path to me))
-- The MainMenu nib contains just the basic edit and window commands, disabling Automator Runner's Quit and Hide
«event appSloaN» "MainMenu" given «class in B»:MyBundle
-- Since all our windows are owned by Automator Runner, it's a good idea to activate whenever displaying something
--activate
-- Windows are quickly unloaded if they are not used. Prepare any data for the initial setup of a window before loading the nib.
--set mp3Icon to load image mp3Icon
try
set progIcon to «event appSloaI» progIcon
end try
«event appSloaN» "ProgressWindow" given «class in B»:MyBundle
tell window "progress"
activate
set «class titl» to progTitle
set «class conT» of «class texF» "upper" to progText
try
set «class imaA» of «class imaV» "icon" to progIcon
on error errmsg number errnum
--display dialog errmsg & return & return & errnum
end try
set «class conT» of «class proI» "bar" to 0
«event appSshoH» it
repeat with i from 0 to (estTime * 10)
delay 0.1
[i]etc etc
[/i]
and, as Gannet said, the scripts won’t even compile.
So, my question, is there any somewhat straightforward way to have a progress bar under Lion? I don’t really have the resources to start a larger project within Xcode etc. Really, I was just relying on the routine that Gannet wrote for the progress bars.
I can remove all of the progress bar code from my script to make it Lion compatible, but would like to keep in the progress bar feature if I can.
Thanks for any advice.
Don
Yes – you can use ASObjC Runner. You run it as a faceless background app. www.macosxautomation.com/applescript/apps/runner_vanilla.html
tell application "ASObjC Runner"
-- set up dialog and show it
reset progress
set properties of progress window to {button title:"Cancel", button visible:true, message:"This is a sample", detail:"More text can go here", indeterminate:false, max value:10, current value:0}
activate
show progress
end tell
delay 0.5
repeat with i from 1 to 10
-- do your other stuff here
delay 1 -- for effect
-- update dialog
tell application "ASObjC Runner"
activate
set properties of progress window to {detail:"This is number " & i, current value:i}
if button was pressed of progress window then
exit repeat
end if
end tell
end repeat
-- hide dialog
tell application "ASObjC Runner" to hide progress
I used ASObjC Runner in my script to display a progress bar. For a variety of reasons, this script has not finally hit live users. (OS update cycle, other changes to our workflow, etc.)
As suggested, I named the script ASObjC Runner-N and placed it in the resources folder of the bundle. it works fine on my machine, but when the script is deployed to our users, they frequently get the choose an application - Where is ASObjC Runner-N.app? dialog.
Below is the code. Any suggestions appreciated.
Don
using terms from application "ASObjC Runner-N" -- needed to compile script
property debug : false
property runnerPath : ""
on run
-- get path to bundled copy, in this case directly in the Resources folder
set runnerPath to (path to resource "ASObjC Runner-N.app") as text
....
and later...
tell application runnerPath
-- set up dialog and show it
reset progress
If you’re using runnerPath as a property, the statement should be:
set my runnerPath to (path to resource "ASObjC Runner-N.app") as text
But I’m honestly not sure that’s the cause of the problem.
I just looked at an earlier version of this script that is on users machines, and noticed that the line:
using terms from application "ASObjC Runner" -- needed to compile script
was missing the -N that is on the copy of ASObjC Runner in the bundle. This must be what is causing the OS to thow up the Where is ASObjC Runner? dialog. Does that seem likely? I know that line is for getting script to compile, could it also affect when the script runs?
Never mind, that change, and the change suggested above did not fix the issue where the script asks “Where is the ASobjC Runner?”
Putting ASobjC Runner loose in the appications folder seems to solve this, even though it is not ideal, that will be the fix I will use.
And, to get ahead on things I put the script onto a test Mavericks machine, and noticed there is an issue with the POSIX PATH command when inside the "using terms from application “ASObjC Runner-N” block. (apparently this is also an issue in 10.8. In the script below, if you comment out the using terms from block this works.
using terms from application "ASObjC Runner-N" -- needed to compile script
set theF to alias "m2:Users:don:Desktop:104megs22"
set thisFilePOSIX to POSIX path of theF
end using terms from
I didn’t know that Automator ran Cocoa-Applescript.
Thanks
Hi gannet,
I tried using cocoa-applescript in an Automator workflow run applescript and the cocoa-applescript didn’t work. Is that what you’re saying?
Thanks,
kel
It shouldn’t, no.
Mavericks is still under NDA, so shouldn’t be discussed here. However, POSIX path is part of standard additions, and shouldn’t be called within an application tell block.
I moved the “using terms from” to only surround the code relevant to ASobjC Runner, and everything is fine. Before I had them surrounding the entire script.
Something did change in at the OS level from 10.6 when I first wrote this script, this was not an issue as it is now under 10.8.
Don
Hi Kel
I realise I’m somewhat late in replying here but if you’re still wondering, the Automator trick only works on 10.5 and 10.6 (I’ve updated the first post to show this). You could try using ASObjCRunner from within a workflow instead.
Cocoa Applet
For anyone else interested, I created an alternative ASOC applet template a while ago for using progress bars in applets. It’s a much improved version of the built-in “Cocoa-AppleScript Applet” template and features easy access to a built-in progress window along with idle support.
Download Cocoa Applet from here
To install, put the template applet in ~/Library/Application Support/Script Editor/Templates/
Then simply open Script Editor and choose File > New from Template > Cocoa Applet.
Read the description shown in the template for help on usage, or check out MacDropUpdate (from the same link above) for a real-world example.