Some days ago, I updated the System from Panther to Tiger. I’m using lots of AS but i can’t solve two problems. Here is the AS parts and the errors:
tell application "iChat"
set a to status of account "somebody@mac.com" -- iChat got an error: NSReceiverEvaluationScriptError: 4
end tell
tell application "Finder"
activate
open folder "Applications" of startup disk
set a to zoomable of front window
display dialog a as text --resut: true
set zoomed of front window to true --Finder got an error: Can't continue.
end tell
The sripts worked on Panther. What is the problem? I have no idea. Panther’s AppleScript better than Tiger’s or something changed what I can’t find in the dictionary?
strange, the dictionaries of iChat in Panther and Tiger look to be equal,
to get the status of an account works with this Code (and should also in Panther)
tell application "iChat"
set a to status of 1st account whose handle is "somebody@mac.com"
end tell
For your Finder problem I coudn’t find out, what’s wrong
I take it that’s a traditional Hungarian greeting.
One has to register as a developer with Apple for the privilege of reporting bugs, so I imagine one would have to do something similar to look them up. I personally rely on my memory and my back-collection of forum discussions. (It’s also a good rule of thumb that if an application’s called “Finder”, it has at least one bug somewhere in its AppleScript implementation.) The problem of setting a Finder window’s ‘zoomed’ property was being discussed on AS-Users soon after Tiger came out in the middle of 2005. A certain Brightonian devotee of multi-statement lines (:P) suggested putting the command in a ‘try’ block and having a GUI alternative in the ‘on error’ section.
tell application "Finder"
activate
open folder "Applications" of startup disk
try
set zoomed of front Finder window to true --Finder got an error: Can't continue.
on error number -10000 (* errAEEventFailed *)
tell application "System Events" to ¬
tell process "Finder" to tell front window to ¬
click (first button whose subrole is "AXZoomButton") -- Uses GUI Scripting.
end try
end tell
This reveals another bug, I think. My own Applications folder window already occupies the full usable height of the screen. When the zoom button (or the “Zoom” menu item) is clicked by script (but not when it’s clicked manually), the bottom of the window disappears below the bottom of the screen, making it impossible to adjust the window size manually. The way round this appears to be to raise the bottom of the window a pixel or two above the bottom of the screen before hitting the zoom button.
tell application "Finder"
activate
open folder "Applications" of startup disk
set {a, b, c, d} to bounds of front Finder window
set sh to (word 3 of (do shell script "defaults read /Library/Preferences/com.apple.windowserver DisplaySets | grep Height")) as integer
if (d ≥ sh) then set bounds of front Finder window to {a, b, c, sh - 2}
try
set zoomed of front Finder window to true --Finder got an error: Can't continue.
on error number -10000 (* errAEEventFailed *)
tell application "System Events" to ¬
tell process "Finder" to tell front window to ¬
click (first button whose subrole is "AXZoomButton") -- Uses GUI Scripting.
end try
end tell
tell application "Finder"
activate
open folder "Applications" of startup disk
try
set zoomed of front Finder window to true --Finder got an error: Can't continue.
on error number -10000 (* errAEEventFailed *)
tell application "System Events" to ¬
tell process "Finder" to tell front window to ¬
click (first button whose subrole is "AXZoomButton") -- Uses GUI Scripting.
end try
end tell
Thanks Nigel! This script is working very well!
Some months ago I wrote a little application in REALbasic. This is doing similar as an old app named “Neatnik”. The app using AppleScript to set window attributes and it is not worked on Tiger but this script solved the problem!
I was afraid that it would be as you say here. I am registered, and (foolishly) assumed that as a registrant one could find a comprehensive list of known bugs with an Apple notation when updates fixed them. Hah!
Gee; I thought that was clear: “A certain Brightonian devotee of multi-statement lines (tongue [firmly in cheek]) suggested putting the command in a ‘try’ block and having a GUI alternative in the ‘on error’ section”. You know, neat stuff like this: :lol:
on byte_units(v)
tell (ln v) div 6.931471805599 to tell (24 - 15 mod (it + 8)) mod 16 to ((v / (1024 ^ (it - 1)) + 0.05) div 0.1 / 10 as string) & item it of {" bytes", " KB", " MB", " GB", " TB", " PB", " EB", " ZB", " YB"}
end byte_units
No, I was angry.