Re: Attachability
Re: Attachability
- Subject: Re: Attachability
- From: Cal <email@hidden>
- Date: Tue, 6 Feb 2001 14:57:39 -0500
Stephen Bryant <email@hidden> wrote:
On 6/2/01 at 12:00, Cal <email@hidden> wrote:
- To make an application scriptable, you have to be a programmer
(probably one who works on that application).
- To support QuickTime in an application, you have to be a programmer
(probably one who works on that application).
- To make an application attachable, you have to be a programmer
(probably one who works on that application).
>See a pattern here? Basically, to implement any OS or Toolbox
service, you have to be a programmer.
Glad we've cleared that up. Anyway:
From the sound of it, Stephen Bryant (the original poster), asked for
information on techniques and uses for attaching scripts. To start
we'll need to know what Stephen means by "attachable".
Consulting the inside of my skull I find this: "Associating a script
that contains a command handler with an application object that
receives a command is called attaching a script to an application
object. An application that supports this capability is called an
attachable application."
Nope. It has nothing to do with the nature of the handler, or even
whether the application receives a command. In an attachable
application, pulling the associated menu item down executes the
script (usually named the same as the menu item) in the Scripts
folder.
>"- An embedded script is a compiled script that's associated with an
interface element belonging to an application or with a document. The
script can be stored with the application's data, often in a special
file known to the application, or embedded within the data for a
document file."
This gets more cloudy. Developers can implement this sort of thing
in their user interface in _any_ way they want (clicking a button can
run a script, dropping something in a container, there's a variety of
possibilities).
It's these possibilities I'd like to find out more about.
And this will vary from application to application, depending on
which user interface elements can be associated with scripts, and
whether the application itself is scriptable. (An application can be
execute attached or embedded scripts without being scriptable itself.
In fact, a lot of them that are attachable, via Scripts menu, aren't
themselves scriptable.)
>[Extra geek topic: There's a third level, tinkerability, where an
application allows a scripter to write a script that overrides the
functionality of the application's implemention of that verb, so that
users and solutions providers can change the behavior of an
application.
How is this a third level? Surely any 'level 2' app that allows a
script to be associated with an interface element can have its
behaviour changed, or am I being dim again?
No. An application that allows embedded scripts merely associates
that script with an interface element -- it doesn't necessarily allow
those scripts to override standard behaviors, like the example of
closing a window, etc. Tinkerability means that you, the scripter,
can change the behavior of that application to override _standard_
behaviors in a non-standard way.
Cal