Increase your app downloads and revenue by including the ability to localize your app into any language. Work with Arabic, Chinese or Japanese in your app just as easily as English. LiveCode 7 has also been reworked to create apps that are even better native citizens. Its buzz phrase heaven: Cocoa, GTK, 64-bit, the list goes on. It means your apps look and perform better on all platforms.

read more

Here is Everything That is New in LiveCode 6.7

Each distinct version has its own complete folder – multiple versions will no longer install side-by-side: on
Windows (and Linux), each distinct version will gain its own start menu (application menu) entry; on Mac,
each distinct version will have its own app bundle.

read more

This release brings automatic scaling and handling of Retina screens to the desktop platforms, in line with the existing iOS and Android support. Also in this release open SSL and encryption support have been added for the mobile platforms. LiveCode continues to increase the feature parity available on all six supported platforms it offers.

We recognize that whilst the mobile platforms are continuing to grow and mature in terms of apps and development, the desktop platforms are vitally important to developers and end users alike. We are proud to offer seamless support for a huge variety of screen sizes, shapes and densities with LiveCode 6.6. Now you can write the same single line of code to handle scaling for your app on the smallest Android device and the largest Mac Retina screens.

Here is everything that is new in LiveCode 6.6

Assert Command (Experimental)

A new assert command has been added to help people who wish to write tests. It was primarily written to support in-house testing of LiveCode but has been documented in the release notes so LiveCode developers can also make use of it with their projects.

High DPI support

High DPI support on windows and OSX has been added meaning LiveCode applications will now run at the native screen resolution on computers with high density screens. For example, the MacBook Pro now comes with a ‘retina’ screen which has 4x the number of pixels than a standard laptop screen. The extra pixels are there to make the apps on screen crisper, rather than provide more screen real estate. By default, the OS up scales applications implemented without High DPI support to the high density screens, resulting in some pixilation. LiveCode 6.6 now creates apps in the new format allowing the OS to render them at the true screen density. The result, your app looks beautiful!

LiveCode CTO Mark Waddingham talks about the High DPI in his blog post titled – Hi-speed HiDPI

ShowAll fullscreen mode

When running a stack in fullscreen mode you can tell LiveCode how you want your app to be scaled. In LiveCode 6.5 we added a number of scaling options and in 6.6 we added an additional one. ShowAll scales the stack preserving aspect ratio so all content within the stack rect is visible. Portions of the stack outside the stack rect will be visible if the scaled stack does not fit the screen exactly.

HTTPS through proxy

The desktop version of LibURL has been updated to support fetching HTTPS URLs through a proxy server. Anyone writing an app that was deployed to a network secured by proxy could not access internet based URLs. LiveCode now supports auto-detection of proxy server settings so that developer apps will automatically tunnel outside of a network with zero configuration.

Image Filtering Updates

Due to a degrade in the image resizing quality in 6.5, the image filtering algorithms have been updated for 6.6.

For LiveCode versions prior to 6.5, the image filtering algorithms were not universal across all platforms. “Good” resize quality used bilinear filtering and “best” used bicubic filtering for all platforms. However, “normal” differed. On Mac, box filtering was used. All other platforms applied no filtering.

For LiveCode versions prior to 6.5, all resize operations were cached (i.e. moving a resized image around did not cause the resize to be recalculated).

For LiveCode 6.5, the image filtering was united across all platforms, with no filtering being applied in “normal” mode, bilinear filtering being used in “good” mode and bicubic filtering being used in “best” mode.

For LiveCode 6.5, only “best” resize operations were cached (the acceleratedRendering mode should be used for caching in other modes). All others were calculated on the fly.

The bilinear filter used in 6.5 was of poorer quality when compared to pre 6.5. Additionally, the “normal” mode on Mac was poorer (due to the loss of the box filter). We’ve addressed this in LiveCode 6.6 by improving the image filtering algorithms across all platforms. “Normal” and “good” mode now use updated algorithms. “Best” mode remains as before.

It should be noted that the improvements to the filters used may cause a slight drop in performance. The final image filters and resize modes used has not been finalized and is open to user input.

iOS 7.1 Support

Support has been added for iOS 7.1. For OS 10.8 and 10.9, LiveCode now uses the iOS 7.1 SDK to produce device builds. As such, OS 10.8 and 10.9 users must have the iOS 7.1 SDK installed (which comes with Xcode 5.1) and configured in their mobile preferences in order to produce iOS device builds.

Open SSL & encryption

Open SSL & encryption support has been added to the iOS and Android engines (using LibOpenSSL version 1.0.1e). This allows developers to use the encrypt and decrypt commands on the mobile platforms in exactly the same way they would on desktop. In order to include the SSL and encryption libraries, developers must tick the “SSL & Encryption” checkbox in the iOS/Android pane of the standalone builder.

SQLite update

The version of SQLite has been updated to 3.8.3. We have also cleaned up the way you connect to the database making it simpler, as well as improving binary data support.

Binary data can now be placed into SQLite databases verbatim (without the encoding that used to occur) – this means databases can be made to contain binary data which is compatible with other applications. To utilize this functionality, the ‘binary’ option must be passed to the revOpenDatabase() call when creating the database connection (see below).

Stack Scale Factor

The new scaleFactor stack property allows you to set a custom scale factor for a stack. If you are working on a stack that is larger than your screen, you can ’zoom out’ by reducing the stack size via the scaleFactor property. The stack appears smaller and all assets are scaled, however, the stack still reports to be its native size.

Hashbangs recognized

Hashbangs ‘#!’ is now recognized by LiveCode Server – this brings the LC Server engine more in line with expected behaviors in the Unix/server scripting world.

55 bug fixes

55 bugs have been fixed in this release making it more stable than previous releases.

Get LiveCode 6.6

Your LiveCode install should prompt you to download this latest release. Alternatively you can download the latest release from the LiveCode Download area.

Find more information on LiveCode 6.6 here.

read more

Resolution Independence

Your app scaled beautifully on any device

Mobile app development is now even easier with LiveCode 6.5. Your stack can now be scaled to run fullscreen on ANY device, no matter its size or aspect ratio. What’s more, LiveCode fully supports high density screens by upscaling text, vectors and automatically substituting in high quality images. Your apps now look stunning on any device.

Best of all, these features are built right into LiveCode and are enabled with just ONE LINE OF CODE!

How to use

No changes and just one line of code

To use this feature with existing stacks requires no changes.Simply tell LiveCode to scale and what your preferred scaling method would be. LiveCode will take care of the rest.

set the fullscreenmode of this stack to “exactFit”

   

read more

6.1.2 Brings iOS 7 Support

The latest stable release offers over 30 enhancements as well as the awaited iOS 7 support

We are pleased to announce the release of LiveCode 6.1.2. This is a stable release containing more than 30 bug fixes and support for xCode 5.0 and iOS 7. We would recommend all 6.1 users upgrade to this release. It is available for both Community and Commercial users. If you have a Commercial 6.x license this release will have automatically become available in your LiveCode account.

The principle reason for existence for this minor point release is to add support for the latest iOS, however as usual we have taken the opportunity to fix various issues and squeeze in a number of enhancements for your delight. Here’s what 6.1.2 has for you.

Engine Changes

iOS 7/Xcode 5 Support
Support has been added to the engine and IDE to allow for iOS builds using Xcode 5.0. This means that OS 10.8 users (required by Xcode 5.0) will need to have Xcode 5.0 installed and set up in LiveCode’s preferences in order to produce Arm v7 builds. Arm v6 builds will still be produced using Xcode 4.4 (the last version to support Arm v6).

The table below details the versions of Xcode LiveCode requires on each platform to produce the given build type. In order to produce universal builds both the Arm v6 and Arm v7 Xcode SDKs will be required.

Platform	Arm v6	Arm v7
10.6	Xcode 4.2 (iOS 5.0)	Xcode 4.2 (iOS 5.0)
10.7	Xcode 4.3 (iOS 5.1)	Xcode 4.6 (iOS 6.1)
10.8	Xcode 4.3 (iOS 5.1)	Xcode 5.0 (iOS 7.0)

In addition to the above, the new iOS 7 icon sizes can be specified in the standalone builder. They are sized as follows:

• Retina iPhone: 120×120
• iPad: 76×76
• Retina iPad: 152×152

Better Quality Printing on Mac
When printing on Mac, two things have been improved. The first is that semi-transparent groups (with default ink – copy / srcOver) will render directly rather than being rasterized first. The second is that PNG and JPEG images will pass their data directly through to the printer driver. The end result is that scaled images will print at higher resolution than they did before in many more cases.

URL Operations Sometimes Fail on Android
There is a bug in the Android Java HTTP layer which can cause URL operations to fail (https://code.google.com/p/google-http-java-client/issues/detail?id=116). This problem seems to be related to keep-alive connections, thus until this bug is addressed in Android the engine will now turn off keep-alive on startup.

Support for Arm V6 iOS Builds Dropped
The earliest version of iOS supported by LiveCode is 4.3. Since iOS 4.3 only runs on Arm v7 (and newer) devices, support for Arm v6 (and subsequently universal builds) has been dropped. This has in turn simplified the versions of Xcode a user needs to have installed in order to perform iOS device builds:

Platform	Xcode Version	iOS SDK Version
10.8	5.0	7.0
10.7	4.6	6.1
10.6	4.2	5.0

Applescript Now Works on LiveCode IDE
This issue has been fixed. It was caused by incorrect naming of the rsrc file – it was LiveCode.rsrc rather than LiveCode-Community.rsrc or LiveCode-Commercial.rsrc. (The name of the rsrc file has to match the name of the executable file within the bundle).

Key Code Parameter to RawKey Messages No Longer Always Zero on Mobile
The rawKey messages will now give pass the ASCII code of ASCII characters to rawKeyDown/Up when pressed. This is consistent with the Desktop’s handling of the rawKey messages.

Spaces No Longer Required in Date Formatting
Date format string parsing has been made less strict in its processing, now collapsing one or more spaces together to allow a ‘ ‘ in a format string to match one or more input spaces. Additionally, spaces in the input after a formatting specifier was successfully matched are ignored. With these changes, both “10:41 PM” and “10:41PM” are accepted as valid times; previously, only the former was acceptable.

Caseless Comparison Now Working Correctly on Linux
For Linux distributions having their locale set to something other than ISO8859-1, caseless comparison was not working correctly. This has been fixed.

Ensure Caseless Comparison Works on Linux Server
This problem was fixed on the Desktop as Bug 11160 and has now been iterated to the Server build.

Offline Activation Now Working in Ubuntu
The installer now does not offer to launch LiveCode after installation as root (e.g. via su or sudo) on Linux in order to prevent the product from creating its activation files with the wrong permissions. Instead, LiveCode should be launched in the normal way after installation and activation occurs then.

A full fix list and more details can be found in the release notes for this edition, here

read more

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.

read more

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.

read more