An introduction to using Libraries, FrontScripts, and BackScripts
in Runtime Revolution's Transcript Programming Language
Fourth World Media Corporation
Copyright ©2004 Fourth World
This document may be distributed freely only in its complete, unmodified form, including this header and copyright information.
Runtime Revolution's scripting language, Transcript, offers an event-driven object model with an easy to use message inheritence scheme. While this native message path is fixed, Transcript includes language features to extend it, including libraries, frontScripts,and backScripts.
Keywords: Runtime Revoluton, Transcript, message path, libraries, scripting, code reuse
Runtime Revolution's Transcript scripting language has a simple yet powerful message inheritance scheme which is inherently extensible to minimize code redundancy and maximize reuse. This article describes how to use libraries, backScripts and frontScripts effectively to achieve those goals.
Revolution's Native Message Path
Phil Davis wrote:
>>Reading is a poor way to learn programming. In any programming language
>>the most meaningful learning is accomplished through experimentation.
>>In 15 years I have met no one who learned programming by reading alone.
> Yes, but... I think some things can be more effectively (or maybe just more
> quickly) "gotten" by reading than by other means:
> - the models and metaphors upon which a language draws for its order and
> vocabulary. These things tell you what you can expect to find as you explore
> the language.
And I fully agree with Judy's (and others) observations about the value
of a good index. Using a variant of the simple indexing example included with MC it could be weighted, so the most relevant hit are at the top.
A comprehensive topical index is labor-intensve to produce (an automated
index only goes so far), but hopefully this is recognized by the good
folks at RunRev as the #1 top priority for any documentation
enhancements in future versions.
> - the vocabulary itself. It's hard to gain comprehensive command of a
> language without approaching it systematically, and that usually means
> following someone else's proven path.
Agreed here too. That's why going through the tutorials and using the Search Documentation tool are so important, so those things can be found.
So just to clarify, my opinion is somewhere between "everything's fine
as it is" and "the docs are horrible". I observe that many have faced
difficulties grasping some of the concepts unique to Transcript (indeed
that's my motivation behind writing articles on it), but I also observe
that a few thousand have come to productive proficiency with even the
current and former docs.
I think it comes down to the intended audience. I bought a professional
development tool, and since Rev wasn't available at the time all I got
was the really sparse MetaCard documentation. But even with the
somewhat poor MC docs, I got far more than what I paid for overall, and
managed to learn enough to get more productive in a few weeks than I'd
ever been before.
I'd purchased Director about the same time as I did MC, and it cost
twice as much for fewer platforms and has (to estimate as generously as circumstances warrant) less than half the documentation.
So the expectations for professional developers established by other
tools in the market may be different from the expectations of students,
educators, hobbyists, etc.
MetaCard was targeted at professional developers and corporations, and
very little of its list traffic was about the docs. If Rev is
interested in other markets I fully recognize that my expectations and
those of others will differ significantly. At that point I believe
we're talking about apples and oranges in terms of expectations, so I
would suggest that neither view of what's "needed" is necessarily wrong.
But beyond that, getting down to essentials there are two very different
goals at play here:
- make RunRev as popular as it can be
- learn what you need to move on with your work
In the long run, of course, serving the first goal will make the second
go away. With the addition of a good index RunRev will further the gap
between its documentation and that of industry giants like Macromedia
Director, and that's a good thing for everyone. I hope it's safe to
assume that the good suggestions posted so frequently here in this
user-to-user discussion forum are also being sent to RunRev, and that
they are being acted on there.
But in the meantime, if the immediate goal is to further one's own
learning, while the documentation becomes ever more useful there are ways to get through the day right now.
I don't have many opinions about any "best" way to teach programming to non-programmers, and if that's where RunRev wants to market I'll leave those expectations to others who have more experience with those audiences.
But for those interested in learning to use Rev to deliver professional work I can share what works for me and the people I help train:
1. Do the tutorials
Before I take someone on for training I have them do those.
If they don't I assume they're not serious and I suddenly
have a booked schedule. ;) Training someone who isn't
really into it is an unfulfilling experience for both.
2. Skim the Transcript Dictionary
Don't read it, flash it card by card, stopping only to read
items of interest. Even with 1000+ tokens the exercise takes
only an hour or two, and its amazing what the mind retains
from even this simple exercize. In my office this is homework
3. Think big, start small
Pick a small project and do it. The smaller the better, so
long as it does at least one useful thing so it will feel
If the person I'm training doesn't have something in mind I'll
often suggest a simple image viewer. We start small, and build
on it as we go. The first iteration merely has one button and
one image object, and clicking the button allows the user to
select an image and sets the filename of the object to display
it. Later we'll move on to file type filtering, then selecting
a folder of images, and eventually make a timed slide show.
Each iteration introduces only a few new tokens and concepts,
and each completed version does something worthwhile.
I had one client who insisted on diving into a very complex
conversion from SuperCard which used objects in ways that are
rarely used even there and made the port very difficult. I
kept after him to cut his teeth on something small first to
get a feel for the IDE and the object model. He never did,
and remained frustrated for a long time.
Everyone else I help train does the think big/start small thang,
and within weeks they're having the time of their lives.
4. Use the "Search Documentation" tool
A majority of the items reported here as MIA can be found using
common terminology to describe them. Note that I didn't say
"all", but a review of the list archives will support my fairly
conservative estimate of "a majority".
For example, no one could expect a newcomer to guess that the
way to purge a stack structure from memory would be to set its
destroyStack property, but only 12 topics are returned when you
search for "purge" and most are obviously not what you're looking
for. Same with hunting down player volume control searching for
"volume" and finding "playLoudness" among the 20 hits returned.
Yes, the searchable index could be improved dramatically, but
its current state isn't a show-stopper if it's used.
5. Join the community using your new language
Doesn't matter which language, human or machine, hanging out
with native speakers is the fastest way to learn. Some see
discussion lists as a necessary evil, but most programmers
I know see it as just part of the process. When faced with
learning any new tool, most folks who want to learn fast
start with one question: "Where's the list?"
There are dozens of mentors on any discussion list, available
24/7 and free. Take advantage of that. If you don't
understand something just post a question and move on to
something else, and in less than a day your answer will be
conveniently delivered to your In Box.
NNTP predates HTTP. That's not an accident. Specialized
discussion groups are a key component to furthering knowledge
in the Internet Age.
6. Learn by dissection
I refer folks to the User Contributions and my own examples
and encourage them to read everything they can find. If
something isn't clear try step #5. Make a copy, dive in, tweak
at will, note what happens. In the worst case you'll just hose
your copy, so you toss it and tweak another.
You simply can't deliver multi-platform apps without knowing quite a bit
about each of the target platforms. You need to know a bit about the
Windows registry, OS X bundles, Classic Finder info, Linux MIME types,
and the basics of events, memory handling, ASCII, file paths, and a
whole lot more. That the good folks at RunRev take the time to cover
those things at all is generous of them, and far beyond the scope of
what most other development tools dare to cover.
If that seems onerous I dare you to boot GCC and try deciphering the
various OS APIs, many of which for all platforms are erroneously
documented (if they are documented at all).
Fourth World Media Corporation
Rev tools and more: http://www.fourthworld.com/rev
path, either with the start using or insert script commands, has its destroyStack property set to true. As of this writing, as soon as you close the stack all of its scripts will be removed from memory with it, so they will no longer be present in the message path.