Your best friend for file transfer.

Seeing error dialog from AppleScript (9 posts)
- Started 18 years ago by John Sandell
- Latest reply 18 years ago from Jim Matthews
-
John Sandell Member
-
Jim Matthews Administrator
Does your script try to close the transfer window in the "on error" clause? I just tried this script:
set aFile to choose file "Pick a file"
try
with timeout of 30 seconds
tell application "Fetch 4.0.3"
put into url "ftp://userid:@host/path/" item aFile
end tell
end timeout
on error
display dialog "Error"
end tryI picked a huge file, and after 30 seconds got the "Error" dialog, but Fetch kept uploading.
It might help to post some of the event log from Script Editor.
Thanks,
Jim Matthews
Fetch Softworks -
John Sandell Member
It doesn't close the window directly in the "on error", but closes it later whatever the outcome after doing other things. Hmm, I need to simplify this script for testing - the upload is in the middle of a big loop and it's difficult to see what's actually happening.
I note you have "tell Fetch...end tell" inside "timeout...end timeout", whereas my script has the "tell Fetch...end tell" as the 'outer wrapper' - does this make any difference in practice?
Thanks and regards
John Sandell -
John Sandell Member
Jim, further to this if I run exactly the same script as you (with only local differences) I don't get any error message. The event log shows:
tell application "Fetch 4.0.3"
put into url...
current application
end tellImportantly, the "end tell" appears in the log exactly at the end of the timeout period, as if something is saying "don't do any more". The upload just stops at this point.
This would tie in with the behavior I've noticed in the live script a couple of times, where it moves on to the place where the Fetch window is closed (it has to happen sometime) without knowing whether the upload completed or timed out.
Thanks and regards
John Sandell -
Jim Matthews Administrator
I don't know why you wouldn't see the error dialog with that script. I'm running Mac OS 10.3.5 -- what version are you running?
A try/on error/end try block gives the script permission to continue after an error, but AppleScript should execute the statements in the "on error" block.
I don't think it makes any difference whether the with timeout statement is inside the tell block or outside it.
Here's the event log I got when I tried to upload a big file:
tell current application
choose file
-- alias "Sirius:Users:matthews:Desktop:Fetch Testing:threegig.bin"
end tell
tell Application "Fetch 4.0.3"
put into url "ftp://ftp.fetchsoftworks.com/incoming/" item alias "Sirius:Users:matthews:Desktop:Fetch Testing:threegig.bin"
current application
end tell
tell current application
display dialog "Error"
-- {button returned:"OK"}
end tellThanks,
Jim Matthews
Fetch Softworks -
John Sandell Member
I'm using MacOS 10.3.1. After setting up this_URL and file_name, my current test script is:
tell application "Fetch 4.0.3"
activate
try
with timeout of 30 seconds
put into url this_URL item alias file_name
end timeout
tell Application (path to frontmost application as text)
display dialog "OK" with icon note giving up after 10
end tell
on error the error_message number error_number
tell Application (path to frontmost application as text)
display dialog "Error " & error_number with icon note giving up after 10
end tell
end try
end tellIf I try to upload a non-existent file I get the expected Error -43
If I try to upload with the router switched off I get the expected Error -3170
If I make it time out by uploading a big file I get the "OK" dialog and it carries on uploading till it's finished. No error message.
If I make it time out by switching off the router mid-upload, I get the "OK" dialog and Fetch sits there for ever. No error message.
Obviously this is a very artificial situation, because "with timeout" is only meant to be a safety net to stop Fetch waiting for ever if something goes wrong. I think what I have to do is use it in this way with a time longer than the expected max, but also to implement a timer in the script to determine whether it's leaving the "try" following a successful upload or a timeout.
Thanks again
John[This message has been edited by jsandell (edited 11-24-2004).]
-
Jim Matthews Administrator
That's so weird. If I run that script with a large file I get a -1712 error message (indicating an Apple Event timeout). I wonder if it's a bug in 10.3.1 that was fixed by 10.3.5 (which is what I'm running).
Thanks,
Jim Matthews
Fetch Softworks -
John Sandell Member
It might well be a bug. I wonder if it's worth updating to 10.3.6 just for that - this Mac doesn't do a lot else. Meanwhile I'm pleased with my scripted timeout check, and it's made me think about and implement choosing a timeout value appropriate to the (very variable) size of the file, as well as monitoring/logging the actual upload speed.
Just one final question: how can the script stop the upload, if it wants to do so (similar to clicking the 'Stop" button in a manual upload)? Or in some way kill the process and close the window without getting the "Fetch is still busy, do you really want to" dialog (which is where we came in.
Thanks and regards
John -
Jim Matthews Administrator
If you say
close transfer window 1 saving no
the transfer window will be closed whether it is busy or not.
I'm glad your timeout code is working well,
Jim Matthews
Fetch Softworks
- Page 1
Topic closed
This topic has been closed.
I use Fetch from an AppleScript to upload files using:
try
with timeout of 300 seconds
put into url...
end timeout
on error...
[error message]
end try
If the upload takes longer than 300 seconds for some reason, Fetch gives an error dialog saying something like "Do you really want to close the window, it's still busy". Obviously I can make the timeout longer (!) but in the end I want to catch it. How can I 'see' this message from AppleScript? Alternatively, can I suppress the dialog and pick up the problem as an error? What I don't want to do is just close the window, I need to know the upload didn't finish.
Thanks and regards
John Sandell
Posted 18 years ago #