GeezerVison

Arrays

Every primitive WinRT array parameter now marshals, on both engines. That covers Int32[], UInt32[], Int16[], UInt16[], Int64[], UInt64[], Single[], Double[], Boolean[], Char16[] and the byte types, and it covers both arrays the callee reads and arrays it fills. Before, only byte[] worked, and a plain JS array for byte[] failed with Unspecified error (HRESULT 0x80004005) (e.g. FileIO.WriteBytesAsync(file, [1, 2, 3])).

• The call passes (count, pointer). The count is in elements, not bytes.

• A typed array of the element's kind, an ArrayBuffer or a DataView is passed in place: the callee reads or writes JS memory directly. A typed array of the wrong kind is refused (Float64Array for Int32[]).

• A plain JS array is copied, converting each element the way the matching typed array would.

• A plain array is refused for a fill array, since the callee's writes would be lost. ParameterDeclaration::is_fill_array() reads the [out] param attribute: is_out() only means ByRef.

• interop.Array.create(type, count) returns the matching zero-filled typed array, so an array can be allocated up front:

  const bytes = interop.Array.create('UInt8', reader.UnconsumedBufferLength);
  reader.ReadBytes(bytes);
  const ints = interop.Array.create('Int32', 4); // Int32Array
  

  Typings added in typings/nswinrt-helpers.d.ts.

Still unsupported: received arrays (out T[], e.g. IPropertyValue.GetInt32Array), array return values, and arrays of strings or objects.

Delegates passed as Object

UIElement.AddHandler(routedEvent, handler, handledEventsToo) takes its handler as Object and unboxes it with QueryInterface(IReference<TDelegate>). We passed the bare delegate, so it failed with E_INVALIDARG, and core falls back to instance events, which never see events a control has already handled.

JS delegates (classic JsDelegate and napi NapiDelegate) now embed a small tear-off (delegate_box.rs) that answers IInspectable and IReference<D>. Its get_Value returns the delegate itself, and its IUnknown methods forward to the delegate, so COM identity is preserved. AddHandler and RemoveHandler work.

The IID comes from GenericInstanceIdBuilder::ireference_of_delegate. A test checks it against RoGetParameterizedTypeInstanceIID. Note that windows-rs signs delegates as a bare {guid} rather than delegate({guid}), so IReference::<SomeDelegate>::IID from the windows crate doesn't match what WinRT uses.

Argument errors

When an argument can't be marshaled, the call now reports why instead of a bare E_FAIL (thread-local error::set_argument_error, picked up by format_hresult_message; napi throws a TypeError). For example: Expected an Int32Array, an ArrayBuffer, a plain array or null for parameter type Int32[]. Two interop tests asserted that such errors contain HRESULT; they now also accept these messages.

Testing

• windows-napi npm test: 442/442.
• New Rust tests: IReference<D> IID against the OS; the delegate box (QI, get_Value identity, refcounts); array element conversion, element counts and view checks.
• End-to-end on Node with windows-napi, 26/26:
  • Array.create for each type.
  • ReadBytes filling a pre-allocated array, and refusing a plain array.
  • PropertyValue.Create*Array for every element type.
  • WriteBytesAsync with a plain array.
  • TextBox.AddHandler(KeyDownEvent, h, true) and RemoveHandler in a live XamlWindow; on main this throws 0x80070057.
  • The same synchronous checks pass on classic V8 (23/23).
• cargo test -p runtime --lib: same failures as main (environment and network dependent), plus enum_type_arguments, whose 2 s wait times out under parallel load on some runs and passes alone.