We are delighted to be able to bring you the first test release of LiveCode 6.6, Developer Preview 1 (dp1) in the last week. The big reason for the existence of this release is to bring the resolution and scaling handling we introduced for mobile platforms in 6.5 to the desktop, but this release is also packed with other goodies guaranteed to put a smile on your face. Top new features include encryption for mobile and updated SQLite support. Also interesting is the new "assert" command.
Scaling and Resolution
You can download some sample stacks here, to see how the new scaling and resolution handling works in practise. You will find the new 6.6 release available for download on this page. Before you begin, please be aware that 6.6 is still an early test release. Back up your stacks, be prepared for unexpected behaviors. Please report any issues you find via our Quality Center, we really appreciate your input. Your early test reports help us to make our releases stable and bug free.
Stack Scaling
The new scaleFactor stack property allows you to set a custom scale factor for a stack. The scaleFactor property accepts a non-zero real number value which represents the scale multiplier. You can use this when developing stacks that are larger than the available screen space - for example developing a stack to be used on an iPad with a retina display. You can also preview the appearance of your stack on displays with differing display densities.
Scaling a stack to half size:
set the scaleFactor of stack "myLargeStack" to 0.5
Preview the stack appearance on a high-density display:
set the scaleFactor of stack "myApp" to 1.5
Hi-DPI support for Windows 7/8 and OSX.
Desktop systems may have multiple displays attached, each with their own density value. On platforms that support different scale values for each display, LiveCode will now automatically render each stack at the correct scale for the screen on which it is displayed. A new global property has been added to allow this feature to be turned on or off if required. The usePixelScaling property controls whether or not LiveCode will automatically apply pixel scaling. If set to false, pixel scaling will be disabled and LiveCode will draw at a 1:1 scale, allowing the operating system to perform any scaling required. When usePixelScaling is false, the pixelScale will be set to 1 and will not be modifiable.
Due to limitations of the platform, applications on Windows will not be able to enable or disable pixel scaling.
On Android there is no equivalent OS-level scaling provided, so pixel scaling will always be used.
Mobile Encryption
Open SSL & encryption support has been added to the iOS and Android engines (using LibOpenSSL version 1.0.1e). This allows you to use the encrypt and decrypt commands on the mobile platforms in exactly the same way you would on desktop. In order to include the SSL and encryption libraries, you must tick the "SSL & Encryption" checkbox in the iOS/Android pane of the standalone builder. In addition to mobile support, LiveCode now includes its own version of the encryption and SSL libraries on OS X (LibOpenSSL version 1.0.1e). This means you are now no longer relying on the system installed security libraries on OS X. Windows and Linux remain unchanged.
Assert
An experimental command has been added to support writing tests. The assert command has two forms. The first form evaluates an expression and checks to see if the it evaluates to true or false:
assert expr
assert true expr
assert false expr
The second form evaluates an expression and checks to see if it throws an error or not:
assert success expr
assert failure expr
In either case if the condition fails, then an assertError message is sent to the object containing the command:
assertError handlerName, line, column, objectLongId
Examples:
assert 1 is 1 -- succeeds
assert true "black" is "white" -- fails
assert false "hello" is a number -- succeeds
assert false 1 + 1 = 2 -- fails
assert success 1 + 1 -- succeeds
assert failure 1 + "z" -- fails
This experimental feature is already attracting comment and debate in the community. The argument centers around whether or not you really need this new way to check for errors - after all, you already have "the result" to catch errors? A very well thought out comment comes from Richard Gaskin on the use-list:
"Before assert was added we had two general ways to check for runtime errors: "the result" is sometimes used for reporting errors, and the errorDialog message is sometimes sent for others (though the "sometimes" aspect makes me uneasy, but that's another topic).
The key point there is that both only catch things the engine considers errors.
Assert compliments those by providing for things which may be syntactically correct and completely executable, yet are errors within the context of the business logic of your app.
That they can also be used for logging execution errors is merely a nice extra, providing one-stop shopping for all types of logging and execution monitoring needs.
Sure, we could write our own handler for some of that functionality, but managing param evaluation would be a bit more finicky and it would have to parse the executionContexts to provide similar info - having this built-in is very convenient.
Many languages support assert, so while it may not be absolutely essential it's a good nice-to-have that raises the level of professionalism in LC.
If you're happy working without asserts they're easy to avoid by just never writing them. :) But I suspect that, like nested behaviors which were questioned here earlier, while the value of the functionality may not be self-evident at first, further exploration will yield new scripting habits that make strong use of them."
What do you think? Will you use the assert command?
SQLite updates and Improvements
The version of SQLite has been updated to 3.8.2, the SQLite RTREE module is now available and SQLite loadable extensions are now supported. To utilize loadable extensions, the 'extensions' option must be passed to the revOpenDatabase() call when creating the database connection (see below). 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
use this functionality, the 'binary' option must be passed to the revOpenDatabase() call when creating the database connection (see below).
The SQLite revOpenDatabase() call no longer requires 5 arguments and only requires a minimum of 2. It has been updated as follows:
revOpenDatabase("sqlite", database-file, [ options ])
The database-file parameter is the filename of the SQLite database to connect to. The options parameter is optional and if present should be a comma-separated list of option keywords. The binary keyword means place binary data into the database verbatim (without LiveCode encoding). The extensions keyword means enable loadable extensions for the connection. Note that the order of the items in the options parameter is not important.
For example:
put revOpenDatabase("sqlite", "mydb.sqlite")
put revOpenDatabase("sqlite", "mydb.sqlite", "binary")
put revOpenDatabase("sqlite", "mydb.sqlite", "extensions")
put revOpenDatabase("sqlite", "mydb.sqlite", "binary,extensions") \
Other new features and changes in 6.6:
- New **showAll** fullscreenmode.
- Image Filtering Updates
- Graphics Library Update
- '#!' now recognised by server
- OS 10.4 (Tiger) Support dropped
- 14 bug fixes
You can read the full release notes here.
