Creating a hierarchy
Everything goes somewhere, but having things in the wrong place can lead to problems. So we should learn more about the structure of a LiveCode stack.
Stack structure
As described in the Background history and metaphors section of this chapter, LiveCode uses a stack of cards metaphor. When you make a new stack you, in effect, have a single-card stack of cards. However, even the simplest application is likely to have more than one card. For example, there could be a splash screen, a title card, cards for the actual task at hand, and a credits page. In the calculator stack we will use two cards. The Tools menu includes an option to view the structure of the stack, by showing the Application Browser:
Where code goes
In programming languages like the one in LiveCode, code is referred to as scripts, while methods or functions are known as handlers (though in LiveCode a handler that returns a value is also called a function). Projects made with harder-to-use programming tools often consist of dozens of external text files, one for each model, view, or controller. In LiveCode this is simpler; the scripts are attached to the object that needs that code.
To deal with user interaction in other tools you will have to write code that receives the event (perhaps just a mouse-click on a button), and to then perform the relevant action. In LiveCode there is a message path that takes care of these events and passes them up the hierarchy. If you click on a LiveCode interface control that doesn't have a mouse event handler, the click goes up the hierarchy to the card level. If the card doesn't have a handler for that event, it continues up to the stack level.
You can have additional levels of hierarchy, by putting other stacks into use, but for our purposes we just need the button, card, and stack hierarchies.
This message hierarchy allows us to place the code needed by several interface controls into a higher level, available to all of those controls. One such case will be with the calculator's number buttons; each one needs to do exactly the same thing, and by putting that code into the card level, each of them can make use of that single handler.
There is no performance advantage to having the shared handler in the card level, or much of a file size improvement, but as you are developing the code for the simple calculator, you can make changes to the single card script, instead of 11 individual calculator button scripts.
We will now start to build the calculator, and add scripts to the 14 buttons, a field, and the card.
Tip
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
