1. Lesson 1 - Background Reading

Embed Size (px)

Citation preview

  • 8/2/2019 1. Lesson 1 - Background Reading

    1/7

    Getting Started Course Lesson 1Finding your way around LiveCode, basic scripting and first applications

    Before you can start writing your first LiveCode application you need to understand the basic structure and

    event driven methodology behind LiveCode.

    Creating a simple graphical applicationin LiveCode can take just minutes. First you create a user interface,

    including any windows, palettes and dialogs you require. Then you populate the user interface with controls,

    like push buttons, check boxes, text fields or menus. Finally, you use LiveCodes English-like programming

    language to tell your application how to behave.

    Structuring your Application

    Cards, Stacks & FilesThe first step in creating a LiveCode application is creating a window, which in LiveCode is called a stack.Each window you see in LiveCode is a stack. Palettes, dialog boxes, and standard windows are all stacks.

    Each stack contains one or more sets of information called cards. Each card can have a different appearanceor all the cards in a stack can look the same. By going from card to card in a stack, you change what's beingdisplayed in that stack's window. You can think of a LiveCode stack as a stack of playing cards (hence thename), where you can flip through the cards, but only one card at a time is visible. A stack can have a singlecard or many cards.

    All user interface objects (controls) are created by dragging them on to a card area.

    You can also group controls together if you want them to operate as a set. For example, if you have a set ofnavigation buttons that go from card to card in your stack, you can make them into a single group. Groupscan appear on more than one card, so your navigation buttons or background image can appear on eachcard of your stack.

    A collection of stacks can be saved together in a single file. This file is known as a stack file. The first stack inthe file is called the main stack and will be loaded automatically when your application is run.

    The Structure of a Stack FileEach LiveCode file contains one or more stacks: either a single main stack, or a main stack and one or more

    substacks. Since each stack is a window (including editable windows, modeless and modal dialog boxes, and

    palettes), a single stack file can contain multiple windows.

    You can use this capability to bundle several related stacks into a single file for easy distribution, to organize

    your stacks into categories, or to allow several stacks to inherit properties from the same main stack.

    Main Stacks and SubstacksThe mainstack is part of the object hierarchy of all other stacks in the same stack file. In other words (for

    the purposes of inherited properties and shared behaviors), the mainstackcontainsits substacks. Events thatare not handled by a substack are passed on to the mainstack's script, color and font properties are

    inherited from the mainstack by its substacks.

  • 8/2/2019 1. Lesson 1 - Background Reading

    2/7

    Dialog boxes and palettes are commonly stored as substacks of the main application window, which is

    typically a mainstack. This allows you to store code and common functions used by all the substacks in the

    mainstack's script. Because mainstacks are part of the object hierarchy of their substacks, the substacks can

    call this functionality from scripts within the substack.

    Stacks, Stack Files, and MemoryA stack file can be loaded into memory without actually being open. A stack whose window is closed (not

    just hidden) is not listed in the openStacksfunction. However, it takes up memory, and its objects areaccessible to other stacks. (For example, if a closed stack loaded into memory contains a certain image, you

    can use the image as a button icon in another stack.)

    If one stack in a stack file is loaded into memory, so are any other stacks in the same stack file. You cannot

    load one stack in a stack file without loading all the rest at the same time even if you open only one of the

    stacks.

    A stack can be loaded into memory without being open under the following conditions:

    A piece of code in another stack read or set a property within the closed stack. This automatically

    loads the referenced stack into memory.

    The stack is in the same stack file as another stack that is open.

    The stack was opened and then closed, and its destroyStackproperty is set to false. If thedestroyStackproperty is false, the stack is closed but not unloaded when its window is closed.

  • 8/2/2019 1. Lesson 1 - Background Reading

    3/7

    Event Driven ProgrammingA LiveCode application is driven by user actions. LiveCode constantly watches the computer for common

    actions, such as clicking on a button, typing into a field, sending data across a network, or quitting an

    application.

    Whenever an event occurs, LiveCode sends a message. When writing your program, you decide whatmessages you want your program to respond to. LiveCode automatically sends each message to the most

    relevant object. For example, if a user clicks on a button, LiveCode sends a message to the button. You

    place code within the button that tells it how to respond to being clicked on.

    There are a wide range of possible events. When a user clicks on a button, a series of events are sent to the

    button. For example, when the mouse first moves within the border of the button a mouseEnter

    message is sent. Then a series ofmouseMove messages are sent as the mouse moves over the button.

    When the mouse button is depressed a mouseDown message is sent. When the mouse is released a

    mouseUp message is sent. You dont have to respond to all ofthese events. You simply place code within

    an object to handle the events you want your application to respond to.

    The Message PathWhen a message is sent to an object, it is often handled directly by a message handler in that object.

    However if no handler is present, the message will continue along a path until it finds a message handler

    that can respond to it. This makes it possible to group similar functionality together at different levels within

    your application. This behavior applies both to event messages sent as a result of a user action, and custom

    messages sent by script. It is therefore possible to write libraries of common functions.

    The object hierarchy is closely related to the paththat a message travels on. In most cases, when an objectpasses a message on, the message goes to the object's owner in the object hierarchy.

    For example, suppose the user clicks a button in a main stack, causing LiveCode to send a mouseUpmessage to the button. If the button's script does not contain a handler for the mouseUpmessage, themessage is passed along to the card the button is on. If the card's script contains a mouseUphandler, thehandler is executed. But if the card does not handle the mouseUpmessage, it is passed on to the card'sstack. If the stack script contains a mouseUphandler, the handler is executed. But if the stack does nothandle the mouseUpmessage, it is passed on to the engine.The engine is the end of the message path, and if a message reaches it, the engine takes any default action

    (e.g. inserting a character into a field or highlighting a button), then throws the message away.

    If a message corresponding to a customcommand or a customfunction call reaches the end of the messagepath without finding a handler, instead of being thrown away, it causes an execution error.

  • 8/2/2019 1. Lesson 1 - Background Reading

    4/7

    Events that are not handled by individual objects can be handled in a number of ways at different levels of

    your application, in libraries, or they can be ignored. We will discuss the rules that govern what happen to

    events that are not processed by an object at a later stage.

    Object-Based ProgrammingAny graphical application you build using LiveCode will be based on objects. With LiveCode you typically

    create the objects of your application before writing any code. You can start by drawing the buttons, textfields, and other controls that make up your application. LiveCode operates like other layout, drawing or

    application development environment. You can select controls by clicking them, move them by dragging

    them around, resize them, and change theirlayer to move them closer or further from the top of the

    interface.

    Once you have the objects in place, you can proceed to attach code to each object to respond to the

    events you want. LiveCode includes a complete graphical development environment that makes it easy to

    create and edit any kind of user interface. It includes objects for all the basic operating system elements,

    including buttons, checkboxes, text fields, menus, graphics, and many more. In addition you can create and

    customize your own objects that look and behave however you want.

    The Edit and Run ModeUnlike most other development systems, a LiveCode application can be created, edited, debugged and run

    live.

    In order to enterrunmode, choose the browse tool in the top leftof the tools palette. In order to edit,choose the pointer tool from the top right of the tools palette.

  • 8/2/2019 1. Lesson 1 - Background Reading

    5/7

    When in run mode, objects receive all the normal messages that drive a LiveCode application. For example,

    clicking on a button in run mode will cause a mouseUp message to be sent to it, causing the button's

    script to run if you've designed it to respond to the mouseUp message.

    When in edit mode, objects do not receive messages when you click on them, and you can move, resize or

    edit the properties for objects.

    Tip:To temporarily stop all messages being sent to your application while editing it, chooseSuppress Messages from the Developmentmenu orToolbar.

    There few other differences between the two tool modes. You can view and edit properties and code ineither mode. Your application does not stop running while you make changes to it. Only mouse interaction

    with objects is suspended in edit mode to allow you to edit them more easily.

    Because LiveCode is constantly live, you can easily make simple changes and watch each change take effect

    as you make it. This allows you to design and experiment using an iterative process, resulting in a more

    productive and satisfying development experience.

    The Application BrowserThe Application Browser contains a list of all open stacks, the cards in each stack, and the controls on each

    card. It allows you to navigate to any card, open or close a stack, select, open the property Inspector for, oredit the script of any object.

    You can access the Application Browser by choosing Tools -> Application Browser.

  • 8/2/2019 1. Lesson 1 - Background Reading

    6/7

    The Properties InspectorThe Properties Inspector allows you to view and edit the properties for any selected object. Properties

    control how an object looks and some aspects of an objects behavior.

    The Inspector can be accessed by double clicking on a selected object, from the toolbar, from the Objectmenu and from context sensitive menus.

  • 8/2/2019 1. Lesson 1 - Background Reading

    7/7

    The Code EditorThe Code Editor within LiveCode has been designed specifically for LiveCode coding. It includes features to

    help make code more understandable. These include code indentation and color coded syntax highlighting,

    as well as other integrated tools such as a Debugger and syntax Dictionary. You can access the Code Editor

    for an object by selecting the object then choosing Scriptfrom the Tool bar. The Code Editor is also

    available from the Objectmenu, and from the context menu available when right clicking or ctrl-clicking an

    object.