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: Sun, 14 Dec 2008 21:39:47 +1100
- Thread-topic: Tell Blocks Considered Harmful (was Re: open for access)
On 14/12/08 8:30 PM, "Chris Page" <email@hidden> wrote:
> For the user-interaction commands, exactly which of the following
> aspects is significant to the correct operation of your scripts?
>
> 1. The dialog is displayed in front.
That's the big one.
>
> 2. The dialog is modal and prevents the user from interacting with the
> target application.
I'd be sad to see that go.
>
> 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.
>
> For example, would it be a problem if we changed all the additions
> that display dialogs to display them in front of the target
> application, but without being modal to the target application? i.e.,
> the dialog would initially be displayed in front, but users and other
> scripts would still be able to interact with the target application
> and the user could even bring the target application windows in front
> of the dialog. What if the dialogs were initially displayed in front,
> but were modal to the process that sent the command?
I think it'd be a shame, but it does have a silver lining: people have often
asked for a way to run a script, have it pause while they do something, and
then have it resume. That's what your proposal offers, I guess.
But what happens in the case of scripts run from apps' script menus or
palettes? In publishing, that's a fair percentage of scripts.
>
>> And the clipboard's dictionary says in part: " Use in a tell¹
>> block..."
>
> I wonder if that documentation is out of date.
It could be -- in any case, the context is in terms of activating the
relevant app.
>> There have also been a couple of apps that have implemented part of
>> their scripting through scripting additions -- QuarkXPress and
>> Photoshop come to mind. In both cases I *think* it related to
>> implementing coercions.
>
> I thought that was only so that a script could perform coercions
> without sending an event to XPress?
I don't know the technical side of things, but without it, you couldn't use
QuarkXPress's "built-in" coercions. In the case of Photoshop, if its
scripting addition was missing, scripts opened as raw event codes. But I'm
talking about a couple of versions back for both.
>
> Is anyone aware of applications that actually use an addition loaded
> into their process to handle scripting commands from other processes,
> instead of just installing event handlers with their application code?
Not me...
--
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