The RR programming model

[Richard Gaskin]

> I've vaguely flirted with Revolution and gone through a couple of
> tutorials but I've never played with HyperCard or other stack based
> systems - and I don't understand the programming model which they
> follow. What is a stack? How do they fit in with more traditional
> programming languages?

You can think of a "stack" as the contents of a window, with a "card" being
one of a nearly unlimited number of screens in that window.  Each stack has
one card when it's created, and you can create more cards with the "create
card" command or make a duplicate of an existing card with the "clone card"
command.  

You could think of a card as being similar in some respects to a VB form.  A
card is where you put controls (buttons, field, images, etc).  Like VB,
Visual C++, and others, controls are placed on the card by drawing them
interactively using the appropriate tool.

Unlike VB, C++, and the rest, these tool modes are also available to you in
scripting -- you can have a browse (normal) mode for interacting with
controls, or a pointer tool mode for selecting, moving, and resizing
objects.  And there are other tools for creating each object type, so you
could have a user create their own fields, for example, using the field
tool.

If you've programmed GUIs without a framework, you know how much code is
devoted to handling the event loop: querying the OS for things like mouse
and keyboard activity, determining which control is affected, and then
calling a function to handle that event.  With the xTalk family of languages
(of which Revolution is one of several flavors, including ToolBook) the
event loop is handled for you:  controls are sent messages that you can
intercept by name --

  on mouseUp
    put "hello world!" into field 1
  end mouseUp

Similar to truly object-oriented systems, messages are sent along a
hierarchy, such that if the first object in the chain doesn't handle it the
message will pass to the second, third, etc.

For example, the "mouseUp" message is sent to the control the user clicked
on, but rather than write code into every button you could put your mouseUp
handler in the card to handle all clicks on the card, or in the stack to
handle all clicks on all cards in the stack.

This message hierarchy is also extensible and malleable to some degree,
using frontscripts, backscripts, libraries, and the send and call commands.

Another big bonus for Revolution: nearly all memory issues (allocation and
deallocation) are handled for you.  Keeping track of object size and
managing associated memory accounts for a huge portion of code in C and
other lower-level languages, but Rev handles all that for you so you can
concentrate on your program logc and user interface.

Once you get the hang of it I suspect you'll find yourself cranking out
applications in a fraction of the time it would take in C, or even Java.

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