Simple Script

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.

Aye. Of course, cscreen hasn’t been failing at all. That’s the most reliable part! :slight_smile:

Can’t believe I called it a block - I should’ve known better. Of course it’s a handler. Thanks very much for the correction.

So that was it. It wasn’t so much that the idle handler wasn’t getting called but that run was never completing. Moreover, your suggestion to use ignoring application responses did the trick. Bravo! I learned something entirely new.

The final source (for now):

(* Must save as a Stay Open Application in Script Editor *)
property appname : "Reading and Phonics"
on run
	do shell script "~/bin/cscreen -x 800 -y 600"
	ignoring application responses
		tell application appname to activate
	end ignoring
end run
on idle
	tell application "System Events"
		if not (exists process (appname)) then
			do shell script "~/bin/cscreen -x 1440 -y 900"
			quit me
		end if
	end tell
	return 2
end idle

Again, thanks tons to everyone for weighing in on this one (… and feel free to keep doing so - or, hmm, yeah, move on ).

Well, i didn’t want to raise your hopes prematurely, but i had a sneaking suspicion it just might do the trick.

Now i’m curious if this will work (eliminating your idle handler):

(* No longer needs to be a Stay Open Application, nor an App at all *) 
property appname : "Reading and Phonics" 
on run 
     do shell script "~/bin/cscreen -x 800 -y 600" 
		with timeout of 0 seconds
			tell application appname to activate
		end timeout
     do shell script "~/bin/cscreen -x 1440 -y 900" 
end run 

I think the with timeout of 0 seconds tells the activate call to wait forever, and i’m hoping it’ll return from the call when the app quits. When the app quits, control will either come back to your AppleScript (as i hope), in which case the second cscreen call is executed, or it will never come back, and your AppleScript is caught waiting for an event which will never occur. If it works, this approach beats the idle handler approach (less system overhead, and may be a regular compiled script).

I like it! A lot more elegant, and it sheds a lot of excess pounds. :slight_smile:

Alas, it never comes back. In fact, this time I have to Force Quit the script editor. Hmm … maybe put ignoring application responses in there? I’ll try it.

HAHAHA - OK, so now I grok that ignoring part a bit more. It ignores the response and plows on through, resetting the screen res. So much for that.

Wow, now I’m curious myself .

Ha ha! That was a good trick! :smiley:

Alas, too bad the shorter script didn’t work! :cry: I suspect the problem is that CGR&P isn’t scriptable and so doesn’t respond to the activate command, thus hanging the script until it times out (should be in about 60 seconds). CGR&P launches because of an implied run command (a command which all applications respond to, scriptable or not). Replacing activate with run might eliminate the need for the ignoring application responses, but hey, it works already, so why sweat it?

I’m surprised you had to force-quit the Script Editor. The stop button should have been sufficient to halt the script.

Good trick, yeah! I’m sure it had some entertainment value in there somewhere .

Well well. I can’t load a dictionary for CGR&P in Xcode, ergo …

Yet another subtlety - run vs. activate. Sure, why not? Other things I’m going to try are setting the volume, disabling the active screen corners, and then restoring them later on.

As for Script Editor, it wasn’t responding to any mouse events. Zero. The window manager was happy - I could move the window, but that was about it. Couldn’t even get at the menu.


Yes it did; definitely worth the price of admission! (Of course i’ve never been there myself! )

Don’t you just love it?

That surprises me. Be that as it may, the default time-out should be around 60 seconds, so control should have come back to you if you were willing to wait. Not that it matters now, but in the future you might have some unsaved changes you don’t want to nuke with a forced-quit. Just FYI.

I gave up waiting after about three minutes. I figured by then it was beyond saving. Bizarre.

I am wondering if anyone out there could help me out on building a simple script. I don’t know too much about scripting so hold tight.

I am printing a PS file over the network into a folder on a server. I need a script that automatically takes any file that appears in that folder and moves it to the printer’s RIP folder. Only the drop boxes are shared on our network, so I can’t directly print to the RIP folder. And I don’t want have the RIP folder shared in our network

I will list exact folder paths to make it easier.

I need any files that get added to
server/users/filserver/public/drop box/lop file server/to print

and move it to
server/applications/hp designjet 20ps RIP/jobs/hp designjet 20ps

To avoid any errors from duplicate named files appearing in the RIPs folder… i was thinking you could (if you are feeling extra nice) script it to trash the file after it is printed in the RIP…

OR

add a suffix to the end of the file name (.a, .b, .c etc)

Though either of these extras are just icing on the ca

this might be getting off topic, but just incase it helps. i know of two one liners in terminal that will kill a process by name.

in terminal
killall Mail
will kill any application with the name Mail.

it should work with any application name

another way to do it is:

ps -aux | grep Mail | grep -v grep | awk ‘{print $2}’ | xargs kill

again, replace “Mail” with a process name.