The Revolution will be programmed, Part II

Last week here in Gearhead I started to discuss a fascinating and powerful programming system called Revolution.

I explained that Revolution is event driven and every event generates a message: For example, starting a Revolution program (which is an event) generates a series of start-up messages, while clicking on an object (also an event) such as a button generates a series of mouse messages (for example, mouseOver, mouseDown, mouseDoubleDown, mouseStilldown, mouseWithin and mouseUp). There are around 200 messages generated by events and Revolution scripts can also generate their own messages.

Before I explain how these messages are handled I need to explain how a Revolution application is organized. A Revolution application is contained in a file and consists of one or more "stacks" (a main stack and optional substacks), each stack containing one or more "cards". Using Revolution's graphical, integrated development environment (IDE) you can create stacks and cards and add objects to them using drag and drop.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Last week here in Gearhead I started to discuss a fascinating and powerful programming system called Revolution.

I explained that Revolution is event driven and every event generates a message: For example, starting a Revolution program (which is an event) generates a series of start-up messages, while clicking on an object (also an event) such as a button generates a series of mouse messages (for example, mouseOver, mouseDown, mouseDoubleDown, mouseStilldown, mouseWithin and mouseUp). There are around 200 messages generated by events and Revolution scripts can also generate their own messages.

Before I explain how these messages are handled I need to explain how a Revolution application is organized. A Revolution application is contained in a file and consists of one or more "stacks" (a main stack and optional substacks), each stack containing one or more "cards". Using Revolution's graphical, integrated development environment (IDE) you can create stacks and cards and add objects to them using drag and drop.

Now, everything in a Revolution application is an object including the stacks and cards. In addition, there are also objects users will interact with (also called "controls") such as buttons, labels fields, text fields, sliders, combo boxes and so on. These get positioned on the graphical layout of cards and can be grouped, making yet another object.

All objects have properties which you can browse and modify using the IDE's property inspector and, beyond the visual attributes (for example, the existence, size, width and color of the borders of a text field) and the control properties of objects (such as whether a text field is enabled and visible) there are scripts that are contained in objects.

Scripts consist of handlers of which there are four types. Message handlers receive messages while function handlers return values when called by scripts. The other two types are special ones that are triggered by requests to get or set object properties.

Scripts can also use functions stored in libraries that add features such as printing, Internet services and manipulate XML data.

So, here's the Revolution script for a simple pulldown menu object (Revolution considers these to be a type of button) called "mainMenu". This menu object displays three options, "Do This", "Do That", and "Status":

on menuPick pItemName
switch pItemName
case "Do This"
<some code>
break
case "Do That"
<some more code>
break
case "Status"
<yet more code>
break
end switch
end menuPick

When the user changes the menu selection a message is generated that consists of "menuPick" and the selected item's text. It is left for the reader to figure out how the switch construct works, but I doubt you'll break into a sweat.

Now, if we wanted to add a button somewhere in the user interface to also show the status we could place a button object to the card with the following script:

on mouseUp
send "menuPick Status" to button "mainMenu"
end mouseUp

You can probably guess what is going on by reading the script. But what if there was no "mainMenu" button object? Well, then the message would be sent down the message path.