Blocking the Timeout (!?)

Scripting Forums AppleScript | Mac OS X
#1

I’ve just stumbled over a construct which seems to block the timeout indefinitely.

” With or without the 'tell' block, this will TIMEOUT at the AS default of 120 seconds, as expected.
tell application "Finder"
	activate
	set dialogName to "abc"
	set theItems to choose from list {"2", "3", "4"} with title dialogName
end tell

-- This construct however, seems to BLOCK the TIMEOUT for ever.
tell current application
	activate
	set dialogName to "abc"
	set theItems to choose from list {"2", "3", "4"} with title dialogName
end tell

Please, can somebody explain why using a ‘tell current application’ block, stops the dialog to ever time out.

If the script is saved and run as an applet, then the ‘choose’ dialog box will float frontmost until the user does something about it. Unless I’m missing something obvious, this seems to be a handy way to ‘kindly’ push a user to deal with a ‘choose’ dialog.

#2

Hi flex20,

With your second script, I can bring some other process to the front. Then the dialog window is not frontmost. But I’m thinking that you’re thinking more about the timeout. You can increase the timeout of a dialog with ‘with timeout’ statement to some large number.

gl,
kel’

#3

Hi kel1,
If you run it as a script, then yes it doesn’t float on top but, try to run it as an applet. The dialog will stay frontmost.

Yes, I know that but, the timeout will still be fixed to whatever you specify. And you also have to deal with catching the timeout error. With the ‘tell current application’ block construct, it seems to be possible to extend the timeout indefinitely.

#4

Leave out the “tell current application” and the same thing happens. AS timeouts relate to when an Apple event is sent to another application; if no reply is received within the limit, the command times out. But in this case you’re not sending an Apple event to another application, so timeouts don’t come into play.

FWIW, “with timeout of 10000 seconds” is pretty close to no timeout in practical terms.

#5

Hi Shane,
Thanks for the explanation. That’s quite clear now.
Leaving out the ‘tell current application’ block, could you also comment on this:

Would that be a viable solution for extending the timeout without having to deal with catching the timeout error?

#6

Hi flex20,

I did run it as application. In fact the dialog window is now underneath the Safari widow. We must have different versions.

gl,
kel

#7

I tried again and here, and when running as an applet, the dialog stays on top of Safari, Excel, System Preferences and any finder window. I don’t know, it may have something to do with versions. I have ML 10.8.3 and current apps.

Cheers, Chris

#8

Well it gets around the timeout. But then setting the timeout to 10000000 gets around it for the best part of four months, which is probably enough for most people :slight_smile:

I don’t see that here under 10.8.3 – I see the same as Kel.

#9

Hi Shane and Kel,
Sorry, you are both right :expressionless: but, I’m just a little bit right myself :wink:
You are correct that AS applets don’t stay on top. My bad :frowning:
But, I’m working at two automator applets and tried a script like that in a Run AppleScript action. There, when saved as an automator applet, the dialog does indeed stay on top. Strange but true :slight_smile:

Cheers, Chris

#10

Hello.

Not exactly in accordance with Apple Design Guidelines, or at least practice, but I sure hope that works in Snow Leopard too. :slight_smile:

#11

Automator applet are different – in that case, “current application” is probably Automator Runner.