Re: Generating applescript files
Re: Generating applescript files
- Subject: Re: Generating applescript files
- From: has <email@hidden>
- Date: Thu, 16 May 2002 18:00:35 +0100
Alex Robinson wrote:
>
Is it possible to generate a file that can then be run as a compiled
>
applescript?
Absolutely.:)
>
I tried the following:
[...]
>
"Could not read the file because of a scripting-system (OSA) error"
>
>
Which I suppose is fair enough seeing that I've basically made a
>
straightforward text file and then just changed the types.
Correctamundo. Your compiled scripts are saved as bytecode [1], not plain
text. Saving your code as plain text and messing with the file type won't
give you a compiled script file.
First, check out 'run script' and 'store script' in Standard Additions.
These are what you need.
You're trying to do two things here: create a script object and save that
script object to disk. Actually, it's more like you're doing *three*
things, since you also want to create the script object from a *string*.
But I'll cover the first two points first, by showing how to create a
script object in the first place.
--
Here's an example of how you'd create a script object which you could then
store to disk:
==============
script scriptObj
set helloString to "Hello world"
display dialog helloString
end script
store script scriptObj in (new file)
==============
Run it, then open the stored script to see how it looks. You might be a
little surprised at first to see that your stored script only reads:
set helloString to "Hello world"
display dialog helloString
but if you think about it the script editing window just shows you the
*content* of a script object anyway.
Think of every script editor window as showing you just the centre content
area of a big script object whose boundaries lie just outside the edges of
your window. Since you never see its edges, you probably never even
realised it was there before! [2]
Just copy my example and experiment with it a bit until you get the hang of
it. As long as you get the general idea, this is all you really need to
know to get started.
--
Now, for the third step:
To turn a string into a script object, you'll need to use 'run script'.
This handy command compiles and executes a string in a single operation,
for example, 'run script "display dialog \"Hello\"' will compile and run a
simple script that displays a 'Hello' dialog.
What we want it to do, of course, is compile and run a script that creates
and returns a script object. Here's some code that does just that:
==============
set scriptObj to run script "
script
set helloString to \"Hello world\"
display dialog helloString
end script"
--> <<script>>
==============
If you add a 'store script scriptObj in (new file)' line to this script,
you can store the returned script object to disk, same as you did last time.
This approach is very useful when you wish to custom-build scripts
automatically: you can join a bunch of strings together to create the raw
code, then use run script to compile and return the finished result. Very
powerful stuff.
NOTE: If there's a disadvantage to 'run script', it's speed [3]. AS has to
load and unload the compiler each time you call 'run script', and this
takes time. If you're doing this sort of stuff a lot, you'll get faster
results using an application that supports a 'do script' function - usually
the same sort of idea, but faster because the application only has to load
the AS compiler once (i.e. when the app launches).
--
Now, the above pretty much answers your question, although there is a lot
more to script objects than I've covered here. If you, or anyone else who's
new to this stuff, have any comments about the above explanation then you
could maybe mail me off-list so I can find out if I'm explaining it in a
way that makes sense or not [4].
HTH
[1] When you compile a script in your script editor, AS parses the text
that you've typed in and converts it into a machine-readable form known as
bytecode. When you subsequently run your script, this bytecode is passed to
the interpreter for execution. This two-stage arrangement is more efficient
than if AS had to (re)parse your code every time you wanted to execute it.
[2] When you begin using AS you don't really need to know about script
objects and stuff, so AppleScript hides certain things that you don't need
to know about in order not to scare you. This makes a lot of sense, but it
can make the learning process a bit bumpy later when you *do* start needing
to know these things.;)
[3] I can think of another, but I've never seen cause problems for this
type of use.
[4] (No doubt the more experienced list members are quietly sniggering at
this<g>, but I gotta take more soundings, okay?;)
--
http://www.barple.connectfree.co.uk/ -- The Little Page of Beta AppleScripts
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.