I'm writing code in AppleScript to glue an Obj-C Cocoa app to some other stuff. I'm very unfamiliar with AppleScript on also learning Cocoa, so of course I have all kinds of bugs in my code to work out, and I need at least some logging.
However, output from the AppleScript 'log' command doesn't seem to end up in XCode's debugger console and calling NSLog doesn't seem to work. Is there any way I can send output to the Debugger Console from within an AppleScriptObjC class method?
(suggestion: new applescriptobjc tag on this Q -- I can't create new tags yet)
I don't use applescriptobjc, so I'm not sure. However, I used to use Applescript Studio so maybe my experience there applies. I noticed that you can't have a log (or NSLog) statement inside of an application tell block of code. Basically if you do that then you are telling the application to log something and the application doesn't know the log command... so it wouldn't work. As such you have to get your log statements out of application tell blocks or use use tell me to log "something" in the tell block... which essentially tells applescript to do the logging.
Not ideal because this logs to the console and uses the shell, but this should at least get you something that works:
log_entry("Hello, World!")
on log_entry(theLine)
do shell script "echo " & theLine & " >> ~/Library/Logs/AppleScript-events.log"
end log_entry
Related
I managed to make Firefox to follow specific protocol links (oxygen:/...) and use an application to open them. As the Mac OS X oXygen XML Developer app doesn't accept arguments, I need to use a shell script that is shipped together with oXygen itself. Given Firefox doesn't like shell scripts, I needed to write an Automator application 'Run Shell Script'. As I was having trouble to get it to work, I decided to use a stub code, with osascript, just to debug variables.
My current script looks like:
osascript -e 'display alert "'"$1"'"'
and it is defined as a bash script, receiving data as arguments.
When I click the link the dialog of osscript appears, but with an empty message. So, I am not sure how the URL is being passed to the application itself. I tried, also, with receiving data as stdin, but with no lock. I got to the point of writing a script that dumped all the parameters and STDIN to a file, but it ends up always empty.
Thank you for any hint.
We have a script to send email using Microsoft outlook or Apple mail application. It will dynamically load the default email from system preference (maybe user input also), and using it to decide which mail client to use.
So the code is as following:
if (mailClientStr contains "outlook")
tell application id "com.microsoft.outlook"
-- <<< there will be error if there is no outlook installed
-- <<< even else branch will be run.
...
end tell
else
tell application id "com.apple.mail"
...
end tell
end if
On an machine which doesn't have outlook installed, and the mailClientStr will be "com.apple.mail", but this script cannot be run by osascript
It complains Can’t get application id "com.microsoft.outlook" even the first branch will not be executed. My understanding is osascript will need to access Outlook apple script interface when load and compile this script (before run it).
I can separate the outlook related code into a separate script, but because there is a lot of data to passing, it will be complex, so I don't want this workaround.
So does there any solution from the apple script language side?
From the AppleScript Language Guide:
Entering Script Information in Raw Format
You can enter double angle brackets, or chevrons («»), directly into a script by typing Option-Backslash and Shift-Option-Backslash. You might want to do this if you’re working on a script that needs to use terminology that isn’t available on your current machine—for example, if you’re working at home and don’t have the latest dictionary for a scriptable application you are developing, but you know the codes for a supported term.
You can also use AppleScript to display the underlying codes for a script, using the following steps:
Create a script using standard terms compiled against an available application or scripting addition.
Save the script as text and quit Script Editor.
Remove the application or scripting addition from the computer.
Open the script again and compile it.
When AppleScript asks you to locate the application or scripting addition, cancel the dialog.
Script Editor can compile the script, but displays chevron format for any terms that rely on a missing dictionary
I have a semi-long AppleScript that I run each morning to launch all of my apps etc. One of the things that it does is launch a few apps and then immediately minimize them. When I paste the .applescript source into Script Editor and run it, everything works fine:
-- snip:
tell application "Mail"
launch
minimize(window 1) of me
check for new mail
end tell
-- 'minimize' defined as:
on minimize(w)
set the miniaturized of w to true
end minimize
But when I compile the AppleScript source as follows:
osacompile -o ~/Library/Scripts/myscript.scpt myscript.applescript
... the compiler munges minimize to be:
on minimize(w)
set |miniaturized| of w to true
end minimize
And I get this error:
error "Mail got an error: Can’t make |miniaturized| of window id 30936 into type reference." number -1700 from |miniaturized| of window id 30936 to reference
Anyone have any clue what I'm doing wrong here? For purposes of version control, I need to run the scripts through osacompile.
UPDATE: To clarify, what seems to be happening is that Script Editor is compiling the method differently than osacompile on the command line. Is it known whether they compile different (e.g., using scope inferences or some such thing)?
There is nothing wrong with your code - I suspect this is a bug in osacompile and I suggest you file a bug report with Apple - as I've done.
You can verify that your code works correctly by using AppleScript Editor to save it as a *.scpt file directly and then running it with osascript.
[Updated] By contrast, passing the *.applescript source-code file directly to osascript does exhibit the problem.
There is no good reason I can think of for AppleScript Editor-based compilation to work differently from osacompile (and on-demand compilation in osascript), and the former's behavior is the expected and desired one in this case.
There are 2 workarounds:
Enclose the reference to miniaturized in a using terms from application "System Events" block:
This is a generic workaround that should work with windows from any AppleScriptable application.
on minimize(w)
using terms from application "System Events" # WORKAROUND
set miniaturized of w to true
end using terms from
end minimize
Inline the miniaturization command instead of calling a subroutine:
set miniaturized of window 1 to true
on minimize(w)
set the miniaturized of w to true
end minimize
This is not correct. You have "miniaturized" outside any application tell block of code, which means that it's an applescript command. It isn't an applescript command though. It's a command of Mail and other applications. It's amazing that it works properly in AppleScript Editor. It really shouldn't. When you have a command that doesn't make sense applescript is good enough to try to make sense of it and sometimes it can overcome your coding mistake. Obviously osacompile can't overcome your coding mistake.
So the way to fix the osacompile issue is to eliminate the coding mistake. You need to have the miniaturized command inside of an application tell block of code.
To see what I mean open the "standard additions" applescript dictionary and try to find the miniaturized command. you won't find it. Now open Mail's applescript dictionary and you will find it. Thus the command belongs to Mail, not applescript.
The Ruby API to Google SketchUp has a function, open_file, but I can't find a close_file function. Since I have to batch process many files, I want to close each file before moving on to the next, otherwise the program will crash from memory exhaustion.
What is the best way to close SketchUp files programmatically?
I am using Mac OS X and am willing to use AppleScript functions to signal the window to close.
EDIT
I am considering a few approaches that have proven fruitless so far.
Using the appscript Ruby gem, as described in this question. The problem here is that I cannot get SketchUp to recognize my installed gems.
In a similar vein, I am trying to use osascript (a bash program that executes AppleScripts from the shell) to close the window. That is, I call out to the shell from SketchUp's Ruby console window using one of the following:
%x[osascript -e 'tell application "SketchUp" to close window 1']
%x[osascript -e 'tell application "SketchUp" to close window 1' &]
%x[osascript -e 'tell application "SketchUp" to close every window']
%x[osascript -e 'tell application "SketchUp" to close every window' &]
Whenever I try this second approach, SketchUp just freezes. However, when I execute any of these commands from an IRB or directly from the Bash prompt outside of SketchUp, I get the desired behavior: the model window closes (incidentally, the Ruby console window remains open, which is fine).
Have a master script that launches a slave script to process each model. The slave will run within the Google SketchUp program while the master waits. When the slave is finished, it signals the master, and the master closes the SketchUp file. To do this interprocess communication, I tried using drb. However, when I try to require drb within SketchUp, I get the following message:
Error: LoadError: (eval):5:in 'require': no such file to load -- drb
EDIT 2
Having a separate process continuously running that closes Google Sketchup windows using AppleScript when signaled is clumsy for a number of reasons. First, it's ugly to have to have a separate process devoted to closing Sketchup windows. Second, the only effective way of communicating with the external script is through the creation of files, which is wasteful and the disk access may be slowing things down.
However, the most severe issue is that Sketchup is slow at responding to AppleScript commands. I have a pretty computation intensive script running in Sketchup, and it seems to starve the AppleScript response, which means that the osascript times out before the windows close. Sketchup only gets around to responding to AppleScript when there is a dialogue box prompt in Sketchup that pauses the execution of my computationally intensive script.
EDIT 3
I have modified my close_file function to pause execution of the script by displaying a dialog box. This essentially yields the current thread and allows the thread that responds to AppleScript commands to execute:
def close_file()
f = '/temp/mutex.txt' # for finer control, use different mutex for each window you want closed
File.new(f, 'w').close
result = UI.messagebox "Click OK when window has closed."
end
Then the separate ruby script that closes windows via AppleScript will additionally have to click "OK" in the dialog box. AppleScript to do that is:
tell application "System Events"
tell process "SketchUp"
set frontmost to true
keystroke return
end tell
end tell
This modification is an improvement. It corrects the "most severe issue" mentioned in EDIT 2, but the other issues remain.
There is an important limitation with using an external AppleScript to force SketchUp to do something. SketchUp will not accept any user input while a menu script is running.
I found this out trying to setup an automated rendering solution. I added a menu item which opens a WebDialog to get a list of models to download from a server. It then steps through the list and uses cURL to download each model. Once downloaded it loads the model, renders it out, uploads the images using cURL again, and goes to the next model.
What I wanted was to activate the AppleScript after each model is rendered (using the "mutex" file solution shown above) and have it close the model window. Unfortunately, since the menu script is still running, SketchUp will not respond to anything the AppleScript tells it to do. Only once all of the models have been processed and the menu script exits, will the AppleScript finally run.
This would not be so bad if all of the calls to the AppleScript were queued up, but they aren't. It seems that only the last two get honored (that number may be just an accident dependent on the timing of when my calls to the AppleScript were made relative to when the menu script finished).
Because of this limitation, I was not able to use the mutex wait() function in my menu Ruby code. Since the AppleScript was not able to execute, it never created its "I'm done" mutex file, and therefore the wait() function in Ruby never got the signal that it could continue. The result was a deadlock between AppleScript and SketchUp, such that SketchUp just freezes up (well, actually it is just stuck in a really tight loop in the wait() function).
So, when approaching this problem, think of AppleScript as a cleanup tool you can call when all of your processing is done.
One solution is to have a separate process continuously running that will close Google Sketchup windows using AppleScript when signaled. The approach described here uses files to do the interprocess communication (drb did not seem to work).
First, you have to make sure Sketchup supports AppleScripting. To do this, execute the following at the command prompt (with appropriate substitutions for different Sketchup versions, etc.):
$ defaults write /Applications/Google\ SketchUp\ 8/SketchUp.app/Contents/Info NSAppleScriptEnabled -bool YES
Now, create a separate file that will close Sketchup windows. Here is my closer.rb file:
#!/usr/bin/ruby
## closer.rb ##
def wait(f)
while !File::exists?(f)
end
File.delete(f)
end
def signal(f)
File.new(f, 'w').close
end
while true
wait('~/temp/mutex.txt')
msg = %x[osascript -e 'tell application "SketchUp" to close every window']
signal('~/temp/conf.txt')
end
Run this script from the shell. It waits until the file ~/temp/mutex.txt is created. Once the file is created, it runs osascript (essentially AppleScript) to close all the windows in Sketchup, and then signals that the windows were closed by creating a ~/temp/conf.txt file.
Here is the client code (which can be placed in your Sketchup plugins) that signals the closer script:
def wait(f)
while !File::exists?(f)
end
File.delete(f)
end
def signal(f)
File.new(f, 'w').close
end
def close_file
signal('~/temp/mutex.txt')
wait('~/temp/conf.txt')
end
The close_file signals the closer script and then waits for a confirmation that the file was closed before returning. Now you can close files in Sketchup.
You can do a lot with SketchUp using applescript and/or Automator.
tell application "SketchUp"
activate
tell application "System Events"
delay 1.0 --close window, adjust delay to suit
--key code 13 using command down -- Press ⌘W or you can use
keystroke "w" using command down
end tell
end tell
I have a number of status bar items for open new, paste to console, closing, killing SU etc.
They're tiny files that trigger the SU shortcut keys, and can be used externally, from 'Ruby Console' or as part of a plugin.
I'm not sure what kind of 'batch convert' your trying to achieve, but
I used Automator to convert most of my old v5, V6, v7 files to v8 today...
100's of them,
and your probably aware, on opening you get 'alert' warning that saving will convert the file to the latest version (which is what I wanted).
It's tricky to click this "OK" programatically.
Automator on it's own is quite restricted, but you can add an applescript to the workflow and I've found that if you use it's 'record function' to demonstrate what you need to do.
You can then copy/paste that code into 'Script Editor', get rid of the 'dowithTimeout' bits, copy it back into the workflow with delays either side and let it run.
I had to play around with delays, to accommodate some larger files, but achieved >95% success. [Success being able to select all, right click, Create Icon and Preview.]
Unfortunately I then binned the workflow, but could recreate it, if you want to have a look.
success, in Ruby Console
system("osascript -e 'tell application \"suoff\"' -e 'activate' -e 'end tell'")
and this script inside an Automator.app in applications folder....
on run
-- Make sure SU is foremost, don't click on anything else either
tell application "System Events"
tell process "SketchUp"
set frontmost to true
-- gives a message if you try to select when SU's not running
delay 0.2
tell application "SketchUp" to quit saving no
-- no dialog box etc...
delay 0.1
end tell
end tell
end run
the problem is SU has an anti self destruct ruby, that mines any linked files and aborts all efforts to shut it down... from inside itself.
so you need to bury it...
this combination works on 10.5.8 with SU8.1.
if you have a look at SketchUcation [Developer] Forum, I left a call for mac/applescript testers... I've rewritten the app since then but if you PM me I'll send you an open copy of all the bits I've got working..
john
I had to convert hundreds of .skp files with a batch processing script. I faced similar issue, since every time I opened a new file it remained opened. For me it was enough to close the active_model and the file goes with it.
This was true for SketchUp 2019 Pro Mac OS X version.
model = Sketchup.active_model
model.save(filename, Sketchup::Model::VERSION_2015)
model.close
Hope it will help
What tips and tricks do you have for debugging AppleScript? Is there a debugger? If not, what is the best way to insert "prints" to display the value of variables? Is there a way to "pretty print" more complicated data structures?
The latest versions of xcode will let you create an AppleScript application but breakpoints in applescript don't work since Apple has discontinued support for AppleScript debugging in xcode.
Fallback: for simple "printf style" debugging you could use:
display dialog "my variable: " & myVar
Script Debugger
XCode
Getting the properties of an object (see below) to understand why it fails, when run from script editor. You can also use the class word, to see what class a property is. The Dictionary for an app is a good starting point.
One technique that often would have helped me, (and that I still sometimes do) is to tell something to return their properties, like this:
tell application "TextEdit"
get properties
end tell
Log statements and Console.app, for debugging of runtime events. (further below). You can ofcourse turn debugging on and off by setting a property
Below is a techniuqe I use for tracking runtime errors, in applets, mail rules, and what have you. When it fails, the error number and message is logged into TestDrive.log, and can be found in the left margin of Console.app…
tell application "TextEdit"
try
set a to text 0 of its name
on error e number n
my logit("OOPs: " & e & " " & n, "TestDrive")
end try
end tell
to logit(log_string, log_file)
do shell script ¬
"echo `date '+%Y-%m-%d %T: '`\"" & log_string & ¬
"\" >> $HOME/Library/Logs/" & log_file & ".log"
end logit
If you're building any amount of AppleScripts, ScriptDebugger is the best tool I can recommend. Having said that...
Xcode is a free option that can be used to develop AppleScripts and can step through code with the debugger. The ability is primarily included so you can build Cocoa applications with AppleScript Studio, but you could use it for any AppleScript development.
If you're looking for something simpler, you might check out Smile, which isn't really a debugger, but does offer features useful for debugging that aren't available in the standard Script Editor.
If a display dialog is too small you can use TextEdit to show big returns:
tell application "TextEdit"
activate
make new document
set text of document 1 to myResults
end tell
Source http://forums.macrumors.com/showthread.php?t=446171
To get the names of windows and other GUI elements and properties, I've found UI Browser invaluable. You can use it to inspect whatever you want to control with AppleScript to find the designations of the elements you want to control
Not free, but easily worth it for a serious developer.
Use the log command. Example:
log "Hello world!"
The output can then be seen in the "Messages" windows in the official editor.
Reference