Today we’re releasing the first developer preview of our next feature release, LiveCode 9. Â In addition to stability improvements, there are some really neat new features to dig into.
By using LiveCode 9 developer previews, you will be able to follow our work on the crowdfunded Infinite LiveCode project.  LiveCode 9 will open a myriad of possibilities to developers by making almost all platform capabilities accessible to your apps.
This first developer preview features important low-level building-block components that will enable the Infinite LiveCode features, but few changes are visible yet for developers working in LiveCode Builder or LiveCode script.
You can get LiveCode 9 DP 1 via automatic updates from within the IDE (‘Help → Check For Updates’), or download an installer.
Faster, better code search
The code search tools in the LiveCode IDE have been optimised to be considerably faster.
Behavior-based app architectures are being used more heavily by LiveCode developers.  To support this, the IDE’s code search tools now recursively search objects’ behaviors as well as their scripts.
Finer control over incoming network connections
Sometimes you want to accept connections from other computers, but only on a specific network interface. Â For example, this is useful when running a VPN:Â one network interface is connected to the Internet and another is connected to your private network.
You can now set the defaultNetworkInterface property to control the network interfaces from which a subsequent accept command will allow connections.
Tab alignment information in HTML and styled text
Since LiveCode 7, it’s been possible to control the alignment of tab-separated text in a field using the tabAlign property.  This property is now represented in the htmlText and styledText of a field.
Better error messages from the LCB compiler
When you compile LiveCode Builder widgets and libraries, you’ll now get much better error messages, showing you the line of code and position where the problem was found. Â For example, when you compile the following code:
module org.example.errors
constant kBadConstant is InvalidExpression
end module
the compiler will now show output:
demo.lcb:2:30: error: Identifier 'InvalidExpression' not declared
constant kBadConstant is InvalidExpression
^
Improving LiveCode’s foundations
The development team has done a lot of work on cleaning up thousands of lines of the LiveCode engine’s source code. Â We’ve used using static and dynamic analysis tools to find and fix long-standing correctness issues in the LiveCode engine, and we’ll continue to work on this throughout the LiveCode 9 development cycle.
Why 9? Better numbering for LiveCode releases
Over the last few years, we’ve found that it can be hard to explain the way we number our releases. For example, it can be easy to confuse LiveCode 8.0.1 (an initial maintenance update to LiveCode 8.0.0) with LiveCode 8.1.0 (a feature release bringing several important upgrades and new capabilities to the platform).
And although theoretically Infinite LiveCode could appear in a hypothetical “LiveCode 8.2”, because it slots nicely in without introducing any backwards incompatibility or need to update existing apps, it introduces enormous new capabilities to LiveCode that definitely would be worthy of a “major release”!
In future, we want to make a really clear distinction between “feature releases” and “maintenance releases”. Â To accomplish that, we’re making a change to LiveCode’s version numbering.
From LiveCode 9, whenever we add or remove features from LiveCode, we’ll update the first part of the version. Â Whenever we make a maintenance release, we’ll update the second part.
So, for example, LiveCode 9.2 will be the second maintenance update to LiveCode 9, and LiveCode 10 will be the next feature release after LiveCode 9.
We hope this will make it easier to know whether you’re getting bug fixes and stability improvements, or exciting changes to the LiveCode platform that may require you to make changes to your app.
4 comments
Join the conversationSean Cole - October 19, 2016
“This first developer preview features important low-level building-block components that will enable the Infinite LiveCode features, but few changes are visible yet for developers working in LiveCode Builder or LiveCode script.”
Why is this the first we have heard about this since the crowdfunding despite the promise on the page that we would get the completed thing with access to objC, C and Java “in the summer of this year, 2016, as opposed to summer 2017”. What happened, why was we not kept informed and what is the new projected timespan? Is it likely that we won’t get it till summer 2017? Or even later, summer 2020? Apple with have abandoned ObjC by then in favour of Swift and we will have missed the boat. SDK14 doesn’t seem to work and we have no other way of making externals. Feeling disappointed, again.
MaxV - October 24, 2016
Hi, may you show some examples of the defaultNetworkInterface? The guide has no evidence of it.
Monte Goulding - October 26, 2016
Yes sure. If you look at the API document about the defaultNetworkInterface you will see that it can be used to ensure sockets are only opened on a single interface instead of any available interface. When this was implemented originally it was only implemented for open socket. We have now implemented it for the accept command. One particular use case where this is nice is if you only need to accept connections from the loopback address (localhost) then by limiting the interface to that you don’t have firewall dialogs popping up. Indeed this is the exact use case I implemented this for where an OAuth2 dialog presents a browser widget which then redirects back to localhost and the dialog script then accepts the connection to determine the auth token.
Albert MEGUIRA - October 27, 2016
I want again to congratulate the LC team for this new version. I know how it can be hard to be a successful technologic company and to deal with economic constraints. I wish to all my LC friends, a successful LiveCode 9 launch.