Grab the latest feature releases for both OpenFL and Lime from Haxelib.
Today’s OpenFL update includes implementations of a number of new APIs from Flash and AIR, including the NativeWindow, NativeApplication, and SecureSocket classes, SampleDataEvent.SAMPLE_DATA for generating audio at runtime, FileReference.upload() on native targets to upload files to a server, and weak event listeners for JS and C++.
On the Lime side, the Window class gained some new properties, a new webassembly target replaced emscripten, a new -eval option allows running Lime tools without Neko, and a new -terser option allows using Terser to minify JS.
Check the changelogs below for even more new features and fixes.
Finally, I’m excited to say that we’ve released new updates for openfl on npm, starling-framework on npm, and actuate for the first time in several years. These versions of OpenFL and Starling allow developers to build projects using JavaScript — including languages that can compile to JavaScript, such as TypeScript, Haxe, and ActionScript 3.0 with Apache Royale). All samples for the npm versions (including JS-ES5, JS-ES6, TS, and AS3) have had their dependencies updated to use the latest versions of OpenFL, Starling, Webpack and relevant compilers. And our Yeoman generators for creating new projects, generator-openfl and generator-starling-framework have been updated with the latest dependencies too, along with swf-loader for using OpenFL library bundles with Webpack.
Changelog
OpenFL
Added SampleDataEvent.SAMPLE_DATA to Sound class
Added openfl.net.SecureSocket class implementation
Added openfl.display.NativeWindow class implementation
Added partial openfl.desktop.NativeApplication implementation, including applicationID, exit(), Event.ACTIVATE, Event.DEACTIVATE, InvokeEvent.INVOKE for launch command line arguments, and properties to test if features are supported
Added openfl.display.Screen class implementation
Added openfl.net.FileReferenceList class implementation for html5 target
Added upload() implementation to FileReference for sys targets
Added updateAfterEvent() to MouseEvent, KeyboardEvent, TouchEvent, and TimerEvent
Added separator and lineEncoding properties to File class
Added localPort, localAddress, remotePort, and remoteAddress to Socket class on sys targets
Added useWeakReference support to addEventListener() on html5 and cpp targets
Added support for referencing environment variables, like %PROGRAMFILES% in File path values on Windows
Added various enum, event, and error types to improve parity with types available in Adobe AIR
Added basic implementation of flash.text.StageText that falls back to TextField, similar to AIR desktop
Replaced String with EventType in FileListEvent, DatagramSocketEvent, and ServerSocketConnectEvent for better compile-time checks
Fixed Flash/AIR compatibility for DatagramSocketEvent, and ServerSocketConnectEvent classes
Fixed wrong type on size for FileReference and File to make it Float instead of Int (Some code may need to use Std.int() after this change)
Fixed missing controlKey property on MouseEvent
Fixed missing Event.OPEN dispatch from download() on FileReference
Fixed corrupted binary files from download() on FileReference
Fixed cut and copy not being blocked by TextField when displayAsPassword is true
Fixed missing Event.OPEN, HTTPStatusEvent.HTTP_STATUS, HTTPStatusEvent.HTTP_RESPONSE_STATUS, and DataEvent.UPLOAD_COMPLETE events from upload() on FileReference
Fixed responseHeaders on URLLoader that should have defaulted to an empty array instead of null
Fixed HTTPStatusEvent.HTTP_STATUS on URLLoader, which should not have included responseURL and responseHeaders
Fixed missing HTTPStatusEvent.HTTP_RESPONSE_STATUS on URLLoader, which is where responseURL and responseHeaders should have been
Fixed runtime exception when using hardware-only texture with beginBitmapFill() by drawing black rectangle instead
Fixed BackgroundWorker deprecation warning when using File and FileStream after ThreadPool is introduced in Lime
Fixed events being dispatched from wrong thread when using asynchronous File APIs
Fixed dragging to scroll in TextField when scaled, by switching to getBounds()
Fixed empty data value on URLLoader when dispatching IOErrorEvent.IO_ERROR and server returned a response
Fixed Vector.ofArray() on flash/air targets
Fixed wrong signature on Socket constructor, which should not have had default values
Fixed incorrect “Lime Application” window title when targeting Adobe AIR on desktop
Fixed missing cleanup code when closing windows and shutting down application that could lead to memory leaks
Fixed event listener issue in TextField by comparing stage values to avoid issues with multiple windows or null stage
Fixed typo in name of Context3DAlphaMaskShader class
Fixed FlashGraphics being included in other targets under some circumstances by adding #if flash conditional
Fixed openfl.globalization, Namespace, and QName issues in npm version
Fixed incorrect condition that caused issues in ShapeCache
Fixed Socket incorrectly dispatching Event.CONNECT for unconnected sockets on Windows
Fixed wrong caps/joints in line style returned by readGraphicsData()
Added openfl_hack_fix_chrome_text define to workaround a bug in Chrome that garbles text
Added openfl_disable_text_measurement_cache define to allow the TextField shape measurement cache to be optionally disabled
Lime
Added visible property to Window to allow it to be shown and hidden
Added opacity property to Window
Added minWidth, minHeight, maxWidth, maxHeight, setMinSize(), and setMaxSize() to Window
Added new onShow and onHide events to Window
Added support for include.hxp file in libraries, similar to include.xml
Added support for multiple file extension filters on FileDialog operations
Added -eval option to run Lime tools without Neko
Added -terser option to Lime tools for html5 builds to optionally use Terser minifier
Added -npx option to Lime tools to run minifiers, or Electron, using npx instead of the bundled versions
Updated the bundled version of Node.js to 18 LTS for the html5 target’s HTTP server
Exposed more information to project.xml, such as ${project.host} and ${config.android.target-sdk-version}
Updated the Android Gradle plugin
Disabled pointer tagging on Android
Fixed issues in emscripten target and renamed it to webassembly
Fixed unpopulated responseData on HTTPRequest when server returns error status code
Fixed Clipboard contents being empty when app starts up on Windows and macOS
Fixed Unicode string conversion for alert() method on Window on HashLink target
Fixed asset cache clearing when unloading asset library
Fixed incorrect timer pause and resume behavior when window goes into background and back to foreground
Fixed .app file extension for macOS when building Adobe AIR captive runtime bundle
Fixed incorrect “Lime Application” window title for Adobe AIR applications
Fixed null check when opening file with FileDialog
Fixed expired Adobe AIR debug certificate
Fixed Haxe 3 compatibility for enum abstracts
Fixed running native apps with current working directory that does not match the program directory
Fixed assets being incorrectly located from Sys.programPath() instead of System.applicationDirectory
Fixed timing on html5 target by using performance.now() so that system clock changes don’t cause issues
Fixed parsing of JNI class names
Fixed cleanup when windows are closed and the Lime application exits
After the update I’m occasionally getting a build error on AIR target:
Called from ? line 1
Called from CommandLineTools.hx line 1903
Called from CommandLineTools.hx line 22
Called from a C function
Called from CommandLineTools.hx line 125
Called from CommandLineTools.hx line 640
Called from lime/tools/PlatformTarget.hx line 98
Called from AIRPlatform.hx line 364
Called from /opt/hostedtoolcache/haxe/4.2.5/x64/std/neko/_std/sys/io/File.hx line 37
Called from /opt/hostedtoolcache/haxe/4.2.5/x64/std/neko/_std/sys/io/File.hx line 53
Uncaught exception - [file_open,Export/air/haxe/debug.hxml]
The curious part is that it doesn’t always happen, only about 1/3 of the times I build it. On the other ones, the app runs without problems.
Interesting. There have been no changes to the file AIRPlatform.hx since Lime 8.0.0 was released over a year ago, so I don’t really have any clues about what might be happening there.
Not a typo. Android changed how you specify the NDK path around AGP version 4.0. Versions before that don’t support the ndkPath property in build.gradle, and instead require ndk.dir in local.properties. So changing >= to < will make old versions of the plugin fail. You’d be better off commenting the line.
Interestingly, it seems ndkPath wasn’t introduced until AGP 4.1, so for 4.0 specifically it will fail. But Lime defaults to 7.3.1, so I wouldn’t think that was the issue.
I do have to wonder how it’s coming up with the string “C:/dev/Android/ndk/21.4.7075529”. ANDROID_NDK_ROOT_ESCAPED hasn’t changed since 2018, several versions back. Can you check .hxcpp_config.xml and/or lime setup android to make sure you didn’t type an extra slash?
Ah! So basically I just removed the ndkpath from build.gradle for my build (that is done with NDK over 4.0). But it worked.
I can confirm that I didn’t type an extra slash. In fact, C: is a correct escaped version of c: and I can observe the Android SDK (not NDK, ANDROID_SDK_ESCAPED) used earlier in the build log escaped like this: c:\dev\Android and it works fine. I’ll be able to send the full build log on Monday. Anyway, I tried different ways (including adding my own local.properties) and could see my changes reflected in the build log, but c: was always there and was causing the error. I could change \ to /, but there is no way to replace :
I could ake the build work replacing ANDROID_NDK_ROOT_ESCAPED by ENV_ANDROID_NDK_ROOT (with whatever slashes in the actual path from the android setup) in the templates as well, so for me the escaped path doesn’t work, but the raw path works fine here.
Lime 8.0.2 doesn’t have ndkPath property in the Android templates btw.
Oh of course, what’s happening is that the escape code puts a backslash in front of any special character it finds, including colons. Can you revert your changes to build.gradle and try this fix instead? (You’ll need to run lime rebuild tools or compile with -eval.)
Great! No idea why the mangled path wasn’t a problem before, but we should be able to get this fixed in the next patch.
Alternatively, we could try the recommended option of using ndkVersion. This could simplify the lime setup android process a bit, because you’d only need to type in the version number, not the full path. And then the Android SDK would be responsible for locating the exact folder.
Actually, this seems like something you could put in project.xml. Maybe you could set a default NDK path using lime setup android, but if you specified an NDK version in project.xml, it would use that instead.
I confirm that Android builds on Windows seem to have broken at some point between Lime 8.0 and Lime 8.1. If I switch back to Lime 8.0.2, I can build for Android on Windows, but I can’t with 8.1.0.
I locally tested the PRs from @player_03 (#1720 and #1721), and they both allowed me to successfully build for Android on Windows again.
I’m leaning towards the second of those two pull requests. Don’t escape so many characters if they aren’t necessary.
Though before we do that, we should track down whoever added that character-escaping code and ask if there was a reason for it. Don’t want to accidentally break anything!
(Makes sense in retrospect. I might be the only Lime dev who regularly uses regexes.)
I don’t recall doing it, but after reviewing some documentation for .properties files, it’s clear I was trying to escape characters with special meanings in .properties files. Of the six characters in the regex, two indicate comments, three are used as delimiters, and backslash escapes characters. However, comments only work at the beginning of the line, and only the first delimiter on a line has any effect, so we never needed to escape those characters. And I guess .properties files ignore extraneous backslashes, so all was well at the time.
I’m trying to use this but it doesn’t seem to work : when calling load() on a FileReference instance because file is null/undefined
from FileReference.hx line 948 : var file = __inputControl.files[0];
through debug I can see that after a successful call to <FileReferenceList>.browse(filterList) every FileReference in <FileReferenceList>.fileList has a zero-length __inputControl.files
Am I missing something or is it not working ? This is with OpenFL 9.3.1 and Lime 8.1.0, trying to load jpg and png files
Thanks, I remember working on this with him as well and proposing a PR but since it wasn’t merged I naively thought it was to make it work like it used to in Flash.
After reading the code from his commit I understand that FileReferences in <FileReferenceList>.fileList are already loaded after the files are selected, so you can use <FileReference>.data right away.
Calling <FileReference>.load() in that context will result in an error. Maybe the html5 code for <FileReference>.load should check if data is populated and just dispatch Event.COMPLETE if it is ?
I believe with Flash we still had to load each FileReference instance (my memory could be bad though !)
:
?