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:
- 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).
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.
Join the conversation