Community Contributions

There are a number of exciting things about 6.1. Perhaps the most interesting and positive aspect of this release is that you, the community, have got involved. 7 features and 2 fixes incorporated in 6.1 were provided by dedicated community members working on the open source engine. Not perhaps earthshaking features in themselves, but handy if you need them, and a great omen for times to come. Just to pick out a couple, Monte Goulding among other items contributed Locking Group Updates, a featuer which speeds up custom controls composed of many objects, as well as the “effective visible”, allowing you to determine which objects are genuinely visible on-screen at any given time. Jan Schenkel gave us “Getting the Page Ranges of a Field” as well as some additional statistical functions, and Mark Wieder fixed a bug with “is a color”. We’re very grateful to all of you!

If you want to get involved, there is a comprehensive guide here, and don’t forget to drop by the forums, here.

Chained Behaviors

Perhaps the biggest new feature in 6.1 is chained behaviors. I’m going to let Ben Beaumont explain to you why you should care about this in your apps.

We introduced behaviors to allow objects to share code. Take for example a platform game where you collect coins. Each of these coins requires the same script in order to function. You can define a ‘behavior script’ and all instances of the coin can use it. Making a change to the behavior script affects every coin.

Behaviors help developers to put more structure into their code and avoid repetition. Repetition is bad because if you need to change some code that is repeated throughout your project, you have to apply that change in many places. Imagine having 100 coins all with the same script. Changing the script means going through and updating the script for all 100 coins!

Chained behaviours takes this code structuring one step further. A behaviour script can now have a behavior of its own which in turn can have a behavior of its own and so on. Lets return to our game example. This time imagine your game involves collecting coins, stars and fruit while trying not to collect poison.

Each of these objects has lots in common:

• When a user interacts with the object it should be removed from the screen
• When a user collects the object their score should change
• When a user collects the object a sound should play

However, these objects also contain differences:

• Each object may move / animate in a different way
• Each object may have a different score associated to it, adding or subtracting
• Each object may have a different sound associated with it

Using chained behaviours you could structure your app as follows which would ensure that no code is repeated in more than one place.

LiveCode Community Activation Removed
In LiveCode 6.1 Community Edition, you no longer need to activate the program after downloading and installing it. This makes it more accessible, faster to install, and removes a barrier to users adopting it. You are still offered the opportunity to create an account if you wish to, but it is not required. Students can easily install in a school environment, making getting LiveCode into more and more of the educational establishment even easier.

You can get the full release notes for 6.1 here, with all the new features and fixes that have been added.

Faster apps

We’ve really gone to town on optimising image performance in this release. Why? Because better image performance means faster apps, especially on mobile. If you have a lot of images in your app, you need them to load fast for the perfect user experience. We’ve worked on optimising images themselves and on image caching so you experience smooth fast app performance.

The engine now has an image cache which is used to cache all decompressed image data. The size of the cache can be set using the global ‘imageCacheLimit’ property, and the amount of data in the cache is returned by the global ‘imageCacheUsage’ property.

The image cache operates in a least-recently-used manner – if an image needs to be decompressed and there is not enough room, the images that were used longest ago are discarded from cache until there is enough room.

If an image has ‘alwaysBuffer’ set to true, then it will be decompressed into the cache on card open. Images are processed from lowest layer to highest, so if too many images have alwaysBuffer on a card, images on lower layers will have their data discarded from the cache before ones higher up.

An image can be forced to be cached by using the new form of prepare:

prepare image <name> [ of … ]
prepare image file <filename>

The image cache is keyed on absolute filename of image thus it is now highly efficient to use image objects referencing the same filename, rather than buttons referencing icons. In particular, there will only ever be one decompressed set of image data for a given (absolute) filename in the cache at any one time.

Better Workflow

We’ve added autocomplete to the message box. Now when you type in a command into LiveCode’s "command line" it will start making suggestions for you to really speed up your workflow and cut down on typing errors. Also, if you use "put" statements a lot, you’ll love the new "Source" feature we’ve added, allowing you to go straight to the statement that generated the output.

Auto-complete

This feature allows you quick access to previous lines of code executed in the message box. Start typing to start the auto-complete feature.

Type – Starts auto-complete
Right Arrow Key – Accept suggested auto-complete
Up Arrow Key – Look forwards through auto-complete suggestions Down Arrow Key – Loop backwards through auto-complete suggestions

Source

The put command in LiveCode outputs content to the message box. The source button loads the script editor and selects the line of code that output the content.

Click – Opens script editor

More Productivity

The new project browser is a big step forward in productivity. You can now quickly find all the elements in your project, and apply common actions to them directly. No more issues with locating invisible buttons, or objects hiding behind backgrounds. Quickly name or rename objects, use the search filter to find items, and generally work with your project efficiently and transparently.

Script of Object
Shows the number of lines of the script of the object.

Click – Opens the script in the script editor

Behavior Script of Object
Shows the number of lines of the behavior script of the object if one is set.

Click – Opens the behavior script of the object

Selected Object
The selected object is highlighted with a change in background color

Click – Deselects currently selected object(s) and selects the target object
Click + Drag – Relayers the object to the drop location
Click + Drag to actions – Performs action on dragged items (ie, new, group, clone, delete)
Shift + Click – Selects all the objects between the currently selected object and the target object Cmd / Ctrl + Click – Selects the target object

Action Bar
The action bar contains a series of buttons that can be clicked on and dragged onto in order to perform the action of the highlighted or dragged object(s).

New – Create a new object of the same type as the highlighted object Group – Group the object(s)
Clone – Clone the object(s)
Delete – Delete the object(s)

Name
The type and name of the object are shown for each object.

Double Click – Makes the name editable

Lock from Selection
Prevents / enables the selection of the object by the mouse pointer in the canvas area.

Click – Toggles the setting

Show / Hide
Shows / hides the object.

Click – Toggles the setting

Expand / Collapse
Expands and collapses the stack, sub-stack, card or group showing / hiding the contents

Click – Toggles the setting

Filtering
You can now filter the controls shown in the Project Browser.

There are a number of way you can do this:

Just typing the the filter field will filter the controls by name.

Alternatively you can specify what you want to filter by, one of name, type, script lines. Name and type use "contains" to match the filter string.

name: <filter string> e.g. name: back

type: <filter string> will filter by type e.g. type: button

script [<|>|=] <integer> e.g. script > 1

The matching controls are shown, along with the groups, cards, and stacks they belong to.

Settings
A new setting icon has been added to the project browser allowing easy access to the preferences.

Take a tour of the Project Browser here.

Better Behaved Behaviors

We’ve introduced "Before" and "After" handlers for behaviors. Why should you care? In a nutshell, it prevents user actions from interfering with your carefully crafted behaviors, causing them to act in unexpected ways when the message they were expecting never arrived. Here’s how it works:

Two new handler types have been added, before and after. Before and after handlers are exclusive to behavior scripts and are sent to the behavior script before and after all messages.

For example, consider a mouseDown message moving through the message path. It gets to an object with a behavior script:

1. The engine looks at the behavior script of the target object – If a before mouseDown handler is present, it executes it.
2. The engine next looks at the object script – If an on mouseDown handler is present, it executes it.
3. The engine now looks at the behavior script – If an after mouseDown handler is present, it executes it.
4. The engine finally looks at the object script – if a pass mouseDown or no mouseDown handler was present, it moves on to the parent object.

Before and after handlers allow developers to produce behavior scripts which can handle messages sent to a control without having any effect on the message path (unlike front and back scripts).

Layers that Relayer

We’ve introduced a "Relayer" command, which means that projects with many layered objects are much more manageable. If you discover halfway through a project that item A should really be underneath item B, but on top of item J which is located in another group of objects, you can now move it around readily and without unexpected consequences. Here’s how it works:

relayer control ( before | after ) layer index
relayer control ( before | after ) control target
relayer control ( before | after ) owner
relayer control to ( front | back ) of layer index
relayer control to ( front | back ) of control target
relayer control to ( front | back ) of owner

All forms work in a regular way – a control is moved relative to a target in one of four ways:

• before – the control’s owner becomes the target’s owner and is inserted before the target; the layer of the control becomes the layer of the target and the target and all subsequent controls shift up one).

• after – the control’s owner becomes the target’s owner and is inserted after the target; the layer of the control becomes one greater than the layer of the last child of the target and all subsequent controls shift up one.

• front – the control’s owner becomes the target’s owner and is inserted after the last child of the target (only valid if target is a container).

• back – the control’s owner becomes the target’s owner and is inserted before the first child of the target (only valid if target is a container).

The target is resolved in one of three ways:

• The engine looks at the behavior script of the target object – If a before mouseDown handler is present, it executes it.

• The engine next looks at the object script – If an on mouseDown handler is present, it executes it.

• The engine now looks at the behavior script – If an after mouseDown handler is present, it executes it.

• The engine finally looks at the object script – if a pass mouseDown or no mouseDown handler was present, it moves on to the parent object.

Before and after handlers allow developers to produce behavior scripts which can handle messages sent to a control without having any effect on the message path (unlike front and back scripts).

• layer – the target control is taken to be the control with layer index.

• control – the target control is taken to be the given control.

• owner – the target control is taken to be the owner of the control.

The control parameter determines the control that is to be moved.
Note that the relayer command can only be used to move controls within a card – attempts to relayer controls from one card (or another stack) to another will throw an error. The relayer command can throw a number of errors:

• ‘relayer: couldn’t resolve target object’ – the target chunk is an invalid control or card

• ‘relayer: couldn’t resolve source control’ – the source chunk is an invalid control

• ‘relayer: source not a control’ – the source chunk resolves to a non-control object

• ‘relayer: target not a container’ – the target chunk resolves to a non-container object (i.e. not a card or a group)

• ‘relayer: source and target not on the same card’ – the source control does not reside on target (if it’s a card), or target’s card

• ‘relayer: layer not an integer’ – the expression passed to the ‘layer’ form is not a valid integer

• ‘relayer: bad layer expression’ – an error was thrown while evaluating the layer expression

• ‘relayer: target not a control’ – in the before or after form, the target chunk resolves a non- control object

• ‘relayer: cannot move a control into a descendent’ – an attempt has been made to move a group into a child of itself.

• ‘relayer: required objects disappeared while processing’ – the target object and/or the source object were deleted in the process of relaying (this can happen when moving controls in and out of groups as messages might be sent to ensure focus is correct).

Other new features include:

• Field improvements –
  • support for Non-BMP unicode characters
  • hexadecimal HTML entity references
  • strong and em HTML tags
  • a new listIndex paragraph property
  • and a new metadata paragraph property
• Effective rect of stack – get and set the rectangular area of a given stack with its decorations and frame taken into account
• Import/export snapshot at size – resize your snapshot before importing it into your project
• Control at location – get the control at a given location
• Split and Combine variants – enables better handling of data in an array
• Object selection started/ended – lets you know when a user starts and finishes dragging over an object

On iOS, support for 6.1 device and simulator builds was added.

105 bugs were fixed in total. Read the full release notes here.