Discover revolution, would like comparison with ToolBook

[Richard Gaskin]

rebolask at free.fr wrote:

> Sorry it was a long time since I asked the question but I didn't have time.

With your ToolBook background i think you'll find it rewarding to download
the demo...

> I didn't try Revolution yet I just read the site. What are the best points of
> revolution which can be found or not in Toolbook.

- Self-contained EXEs (no DLLs strewn al over the user's hard drive)

- Runs on nearly every major desktop OS

- Somewhat simpler syntax (no data type declarations, simply "on" instead of
"to handle")

> If you know Tollbook very well (I have been an expert with this product by
> being a consultant for Asymetrix and forming developpers but I gave up this
> product because Asymetrix has been a disaster commercially in France)  :
> 
> - it doesn't seem to support Activex whereas Toolbook does (Toolbook is not
> multiplatform)
> then are components limited to revolution's ones ? For example I didn't see
> any tree component so how would you show for example a xml-type structure ?
> advanced GUI: support of thin caption and always on top window

Rev's groups can be nested.  In cunjunction with centralized code in
libraries, this can make for very powerful complex objects that can be
custom-built.

There are a few tree controls and othr widgets and tools available at:
<http://www.RunRev.com/Revolution1/developercentral/usercontributions.html>

Rev also supports an interface for compiled code written in C.  While the
externals themselves would of course need to be compiled for each platform,
the API is the same on all supported OSes.
 
> - equivalent of Toolbook's script in groups and if possible sharescript
> (script shared between several groups) ?

The message path is almost identical to ToolBook's, and like ToolBook there
are ways to insert scripts of other objects into the message path.

Rev has frontscripts, which catch all messages before the natural target
gets them.  This could be useful for logging for example: when inserted you
could log all events to a file and then just pass the message to resume
normal handling; to turn off logging you just remove the logging script from
the frontscripts queue.

A corollary to frontscripts are backscripts, which as the name implies
reside in the very back of the message path.

Any object's script can be inserted into the frontscripts and backscripts.
You can have up to 10 frontscripts and 10 backscripts at runtime; there is
no practical limit when running in a licenced development environment.

In addition to frontscripts and backscripts Rev has libraries, stack scripts
inserted into the back of the message path with the "start using
<stackName>" command.  Libraries are behaviorally distinct from backscripts
by the additoin of messages sent to the object being libraried providing
notification of when it's brought into use and when it's removed from use.
You can have up to 50 libraries at runtime, with no practical limit when in
a licenced IDE. 

Rev supports just about all of the syntax for all forms of shared scripts in
HyperCard, SuperCard, and OMO, but not all of ToolBook's:

If memory serves (my last major ToolBook project was delivered in '98),
ToolBook has one nice feature not currently supported natively:  the ability
to a specific script as the parent to specified objects.  This is part of an
ongoing discussion of proposed language features features on another list,
and at this time it in uncertain when such a feature will find its way into
the engine and what form it mnight take.

In the meantime, if this functionality is important to you there are a
couple different ways to implement parent scripts using native Transcript,
with the limitation that it can only re-route system messages.  For example,
you could have all "mouseUp" events for a certain objects handled by one
shared script and for other objects a different shared script.  If you need
it, I have a very modest example I threw together some time ago called
"libD'oh!" (the poor man's OOPS) I could send you.

 
> - equivalent of design (author) mode which can be scripted like runtime
> (reader) mode

Absolutely. One of the strengths of most xTalks (Rev, MetaCard, SuperCard,
OMO, Gain Momentum, and of course ToolBook) is that the IDE itself is
scripted, making it easy to extend and modify.

Inevitably a project will have unique challenges that could benefit from
production support tools to full automation; Rev can deliver both and just
about everything in between.

The Rev tutorials are a good example:  When I wrote the first several
drafts, I wanted to be able to focus on the instructional flow and not get
bogged down in object layout.  I knew we'd be going through several
revisions, so I invested a couple hours up front making a tool that reads a
text file marked up with simple tags and uses that to construct the
tutorials from a template stack.  This allowed for much easier editing and
review, and completely separates UI from content so either could be changed
without affecting the other.

The licensing of the runtime engine is unusually liberal, allowing nearly
all tasks except serious script to be performed from a standalone.  This
allows you to build custom content management systems, layout tools, etc.
for team members while you get back to coding.

Within the IDE itself, Rev provides easy extensibility with the
Development->Plugins menu.  Just make a utitity stack and drop it in the
Plugins folder, and next time you boot Rev it's in the menu.

I don't think there's another tool as close to ToolBook as Rev.  And if by
chance you find yourself doing contract work for the Munich government,
you'd have to use a tool that can deploy on Linux ;)
<http://news.com.com/2100-1016-1010740.html>

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Developer of WebMerge 2.2: Publish any database on any site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc