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"
break
case "Do That"
break
case "Status"
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.
This path really starts with the “frontscript” where handlers can be placed to trap system or user generated messages before any other handlers further down the path, including those in the object’s script, can do anything with the messages.
If there’s no handler in the frontscript or the object’s script and the object is a member of a group then the message is passed to the group’s script. If there’s still no handler the message gets passed to the script of the card the object is on, then to the “background” script (backgrounds are groups for cards), then to the stack the object is on, then to the main stack if the object is on a substack, then to the “backscript” (a catchall step on the path and the group of all stacks). If there’s still no handler the message is passed to the Revolution engine, which will then execute the default action for the message and the object.
For example, if a key is pressed in a text field object, a “keyDown” message is generated, which includes the key that was pressed. Obviously a handler could be placed anywhere in the path to trap and remove or modify keyboard data as it is entered, but if there isn’t one then the Revolution engine will get the message and do the default action for that object, to wit, update the text field display.
In other words, using Revolution you can handle system and user events at any level of detail providing as fine-grained control over the user interface and application behavior as you need.
Next week, into the “candygrammar” of Revolution.
