Previously, it seemed that only Windows HashLink would hang when opening a FileDialog, but I was able to reproduce #1946 on Windows CPP too. Not sure why I couldn't before because I don't see any obvious changes to FileDialog or ThreadPool that would cause it to happen now, but not when it was affecting HashLink previously.
Does not seem to affect other operating systems.
We might consider going back to BackgroundWorker instead, which we used in Lime 8.1 and older.
openal-soft assumes that aligned_alloc is available with c++17. Newer
android ndks set c++17 by default, however they do not expose
aligned_alloc without setting min sdk version to 28.
We can avoid this issue by forcing openal to be compiled with c++11.
Also note, we have HXCPP_CPP11 defined, however, hxcpp ignores this for
the android toolchain. This means we must set it explicitly
See:
f5e0eef34d/common/almalloc.cpp (L15)
Hxcpp doesn't respect HXCPP_CPP11 for android. We can avoid this issue just by adding -std=c++11 here. This resolves a conflict with openal soft 1.20.1 for android builds. This works because the library assumes c++17 and invokes a function that isn't available in android sdk below 28.
clang: warning: include path for libstdc++ headers not found; pass '-stdlib=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
This change moves away from purely hard coding the minimum sdk version for android and also correctly sets the PLATFORM_NUMBER define. The gcc toolchain is no longer compatible in lime 8.3.x+ so, we shouldn't have to worry about the PLATFORM define at all.
It might be wise to enforce a baseline minimum version and complain if users try to use something lower than the default.
If the text is invalid, then readNextChar returns -1 and does not
progress to the next character. This previously meant that we got stuck
and looped indefinitely.
Previously, the first for loop would reach the end of the characters, so
no further characters were read in the second loop. This meant that the
array remained filled with 0 values.
To properly handle encoding conversions, we need to do it in native
code. This new function performs this role.
This is useful for hxcpp which may have either ascii or utf16 encoding,
but this can only be checked via the native api and it is not possible
on the haxe side.
This function wants the utf8 length, but text->length does not give
this. We can instead use -1 to tell harfbuzz to treat it as null-
terminating, which is the case with all hashlink strings anyway.
A HxString is not guaranteed to be utf8 on hxcpp, so we need to use
hxs_utf8 to convert it otherwise it incorrectly displays any utf16
encoded string.
Unfortunately, hxs_utf8 doesn't give us the length of the utf8 string.
The best thing we can do is to tell harfbuzz it is null terminated. This
isn't perfect because technically hxcpp strings are allowed to contain
NULL, but it's better than all utf16 strings being broken.
