The GDScript version above makes the `number` property read only whenever
`is_number_editable` is false.
```gdscript
func _validate_property(property: Dictionary):
if property.name == "number" and not is_number_editable:
property.usage |= PROPERTY_USAGE_READ_ONLY
```
The C# version is similar, but omits the negation, so the Number property is
made read only whenever `is_number_editable` is true.
This adds the negation to the C# example, making it match the GDScript
example.
The following is the currently generated `EditorImportPlugin.cs`:
```csharp
public virtual Error _Import(string sourceFile, string savePath, Dictionary options, Array<string> platformVariants, Array<string> genFiles)
{
return Error.Ok;
}
```
This fixes the type signature in the documentation's example to match the
actual type signature.
Before, multiple capability events would instantiate the same object
over and over as long as its bit was set. This caused issues with
hotplug and device suspension.
C# uses `long`s to access many native values. With `PtrToArg<m_enum>` and
`PtrToArg<bitfield<m_enum>>` this isn't a problem, as C++ code converts
through a `*(int64_t*)` cast in assignment, so all 64-bits are initialized.
However, with `PtrToArg<char32_t>`, value assignment happens through an
`*(int *)` cast, leaving 32 bits uninitialized where `int` is 32 bits. On
platforms where `int` is 16 bits, there are presumably 48 bits uninitialized,
though there are very few platforms where this is still the case.
The easiest way to see the practical effects of this is by looking at
`EventInputKey.Unicode`:
```csharp
public override void _Input(InputEvent @event) {
if (@event is InputEventKey keyEvent) {
if (keyEvent.IsPressed() && !keyEvent.Echo) {
var raw = keyEvent.Unicode;
var value = raw & 0xffffffff;
GD.Print($"Key pressed: raw: {raw}; masked: {(char) value} ({value})");
}
}
}
```
Pressing 'a' emits the following line:
```
Key pressed: raw: -3617008645356650399; masked: a (97)
```
Examining execution flow in gdb shows this conversion going through the
following line:
```
PtrToArg<char32_t>::encode (p_ptr=0x7ffcd5bb4b18, p_val=97 U'a') at ./core/variant/binder_common.h:221
221 *(int *)p_ptr = p_val;
```
Here, `p_val` is still 97, which is the value `InputEventKey.Unicode`
is expected to have. After assignment, `p *(int64_t *)0x7ffcd5bb4b18` displays
`-3617008645356650399`, with only the lower 32 bits being properly assigned,
and is the value we see from C#.
With this patch applied, the above testing `_Input` now prints:
```
Key pressed: raw: 97; masked: a (97)
```
Thank you to blujay1269 for asking about an unexpected value they saw in
`EventInputKey.Unicode`, which prompted this investigation.
Capitalization fix in test_style_box_texture.h
Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro>
Newline fix in test_style_box_texture.h
Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro>
`GDExtension::open_library` has a check in it to see if the library was loaded
from a temp file, and if it was to restore the original name as that is the one
we actually care about. This check is breaking extension reloading on Mac when
the library path is to a framework folder, as the file inside the framework
will not generally be the same name as the folder.
This check also shouldn't be necessary even on Windows, which is the only
platform that uses `generate_temp_files`, since disposal of the created temp
file is handled within `OS_Windows::open_dynamic_library`, and
`GDExtension::open_library` (which is the only function to call
`open_dynamic_library` with a `p_data` argument) only cares about the original
library file path and has to do extra work to remove the name of the temp file.
Instead, I have removed that check and set `OS_Windows::open_dynamic_library`
to return the name of the original file and not the name of the copy.
This fixes GDExtension reloading on macOS. I do not have a Windows machine
available to test that it still works properly on Windows, so someone should
check that before merging this.
In future work we may want to expose an isStylus or similar for
XR Trackers, though that is likely outside the scope of this commit
which is the core extension work.
Vendor Ref: https://logitech.github.io/mxink/OpenXR.html
