There is a difference between Jon’s use of it and mine: I put the quit me outside of it. I’m assuming that if the do shell script "~/bin/cscreen -x 1440 -y 900 fails the first time through, it’ll fail on subsequent passes too, so you’ll want to quit rather than get stuck in an infinite loop. Jon’s use assumes that it will, at some time, succeed. The best approach might be to put an error handler in there which brings up a dialog and asks the user whether to try again or quit? If it’s try again, then return 30, or some other sufficiently long delay.
The correct terminology, in this instance, is not “block” but “handler.” “Block” is sometimes used to refer to smaller sections of code, like a “try” block, or “if” block. Usually some compound statement which ends with an “end” statement.
You are correct in how the flow should occur. Try putting a beep 3 right after the CGR&P call to see if control returns right away or not. If not, embed the call in an ignoring application responses block like this:
ignoring application responses
tell application "Reading and Phonics" to activate
end ignoring
It sounds to me – if the idle handler is never called – that your run handler is never finishing. Put a beep 2 preceeding the delay 35. If you don’t hear the beeps, i’ll bet it’s the CGR&P call, alright. Of course the ignoring application responses should take care of it if that is the problem.
One thing to try, if it is the cscreen call (which i tend to doubt) is to make the call like this:
try
do shell script "~/bin/cscreen -x 800 -y 600"
on error the error_message number the error_number
display dialog "Error: " & the error_number & ". " & the error_message buttons {"OK"} default button 1
end try
That will yield some diagnostic info.
I’ve had the Finder lock up on me before, where a force quit was not possible and a reboot was the only recourse. Has usually been related to using its “connect to server” option to connect to a finicky FTP server.