They were using float values, but they should have been int values instead.
The numeric type conversion was causing some kind of data loss that resulted in wrong values being returned in some cases. In particular, arrow keys.
Documented semver-based versioning flow
- Explained usage of patch (develop), minor (x.x.x-dev), and major (x.0.0-dev) branches
- Added guidance on where to submit bug fixes, new features, and breaking changes
- Improves contributor clarity and aligns with current project workflow (e.g., Lime 8.2.2 -> 8.3.0-dev, 9.0.0-dev)
This helps reduce confusion about where to submit changes and ensures consistency across releases.
For non windows platforms, we previously just passed char* into wstring,
which didn't perform the necessary conversion into utf32 which is
expected when hxcpp converts a wchar string to a hxstring on platforms
where wchar has 4 bytes.
If HOME is NULL, we cannot return here immediately, since we haven't
called `System::GCExitBlocking()`. This currently causes:
```
Critical Error: Allocating from a GC-free thread
```
This is already handled correctly for `USER` and `DOCUMENTS`, however
`DESKTOP` was missed out in f6e38208d3
Followup to 6f2f88ca74
Now checks for devices with filters in the following order of preference:
1. State == 'connected' AND transportType == 'wired'
2. State == 'connected' AND transportType == 'localNetwork'
3. State == 'available (paired)' AND transportType == 'wired'
3. State == 'available (paired)' AND transportType == 'localNetwork'
Also adds developerModeStatus == 'enabled' filter as a requirement for all checks.
If the app is meant to be iPhone-only or iPad-only, adds the appropriate filter for that too.
I assume we used `untyped __js__` to get around incomplete externs, but Haxe 3.2 updated the externs, and they've included the second argument ever since.
If the version of Lime tools doesn't match the version of Lime specified by <haxelib version/>, and Lime is found in .haxelib, append the -nolocalrepocheck option to avoid redundantly checking for .haxelib again and potentially comparing to a path resolved without accounting for <haxelib version/> yet.
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.
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.
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.
