Re: Tell Blocks Considered Harmful (was Re: open for access)
Re: Tell Blocks Considered Harmful (was Re: open for access)
- Subject: Re: Tell Blocks Considered Harmful (was Re: open for access)
- From: Shane Stanley <email@hidden>
- Date: Mon, 15 Dec 2008 09:20:19 +1100
- Thread-topic: Tell Blocks Considered Harmful (was Re: open for access)
On 15/12/08 12:11 AM, "Chris Page" <email@hidden> wrote:
> Why is that important for your scripts? Is it critical for correct
> operation or just nice-to-have? Do you need to be able to prevent the
> user from interacting with the target application?
It's often critical. A typical script might be as follows: first check that
the conditions are right (the correct thing is selected or whatever),
sometimes deciding on what dialog to show based on them, then bring up the
dialog, then act. If someone can make changes while the dialog is up,
failure is going to follow.
>
>>> 3. The contents of the file-related commands depend upon the
>>> permissions of the target application.
>>
>> I'm still trying to get my head around the idea that the apps *have*
>> different permissions -- I don't think I've seen the issue raised in
>> a practical situation. I may be wrong, but I suspect this is a
>> complete non issue.
>
> What's the complete opposite of ³non-issue²? That's what this is. ;-)
Sorry, I was talking in terms of scripters relying on their scripts being
addressed to apps to get access to something they can't otherwise. I think
it's a non-issue in terms of how your proposed change would affect most
scripts, in that I've never heard of anyone relying on it to get things
done. Maybe I live a sheltered life...
>> But what happens in the case of scripts run from apps' script menus
>> or palettes? In publishing, that's a fair percentage of scripts.
>
> I don't quite follow you. Currently, if you run a script within an
> application and it does display alert¹, the dialog will be within
> that application and it will be modal, preventing the user from
> interacting with that application. If the script tells Finder to
> display the alert, the dialog is within Finder and the user can't
> interact with Finder or the Desktop, and the script pauses until the
> user dismisses the dialog. Depending on the application running the
> script, it usually also means that application doesn't respond to user
> input while the script is paused, either.
>
> What I'm suggesting is, when display alert¹ is inside a Finder tell
> block, what if the dialog weren't displayed in Finder's process? The
> user would be able to interact with Finder while the dialog is
> displayed. But the script would still be paused waiting for the
> response, and the application running the script would still be
> waiting for the script to resume execution.
>
> We could accomplish this either by displaying the dialog inside the
> application running the script or by creating another process that
> exists specifically to display dialogs for scripting addition
> commands. In either case, the script pauses and the application
> running the script pauses until the user dismisses the dialog.
What I'm asking is whether, if the script is being run by an application --
let's say InDesign via its Scripts panel -- would it then block interaction
with the app via the UI?
The more I think about it, the more I think moving dialogs outside apps
would be a backwards step (although the ability to do it *either* way would
be a step forward).
> My point is: Do the clipboard commands work correctly without a tell?
> Does it matter which process they're handled by? Is it necessary to
> activate an application and send it clipboard commands for them to
> work correctly? It used to be true that the clipboard could only be
> accessed by the active application process, but I don't know whether
> that's still true.
Neither do I -- I can't remember the last time I used them. I think the
documentation was suggesting that making an app active is sometimes needed
to make stuff on an app's own clipboard available generally.
--
Shane Stanley <email@hidden>
AppleScript Pro Florida, April 2009 <http://scriptingmatters.com/aspro>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden