microsoft/windows-rs

Bug: Inherited interface members are not generated for XAML controls

Closed this issue · 3 comments

Which crate is this about?

windows

Crate version

0.35.0

Summary

For Windows Runtime types, inherited interface members should show up for coclasses that derive from those interfaces. This doesn't appear to work (any more) for stock UWP XAML controls.

Toolchain version/configuration

No response

Reproducible example

use windows::{
    core::{IInspectable, Result},
    UI::Xaml::Controls::Button,
};

fn main() -> Result<()> {
    let btn = Button::new()?;
    btn.SetContent(IInspectable::try_from("🦀")?)?;

    Ok(())
}

Crate manifest

[package]
name = "itf_inheritance"
version = "0.0.0"
edition = "2021"

[dependencies.windows]
version = "0.35.0"
features = [
    "UI_Xaml_Controls",
]

Expected behavior

The code should compile.

Actual behavior

The compiler issues the following error:

error[E0599]: no method named `SetContent` found for struct `Button` in the current scope
 --> src\main.rs:8:9
  |
8 |     btn.SetContent(IInspectable::try_from("🦀")?)?;
  |         ^^^^^^^^^^ method not found in `Button`

Looking into the generated impl Button block it seems that only the immediate Button members are generated. None of the derived interface members show up.

Additional comments

This used to work as expected in the past (such as 0.18.0, using the build! macro). It also appears to work with the Windows App SDK/WinUI 3 (as illustrated in this sample). It just doesn't work with the stock UWP XAML controls (I haven't checked WinUI 2).

Hi Tim, this is by design. I would like to get rid of Xaml altogether as it only works well with C#. Initially, I just attempted to reduce the impact of its huge API surface by limiting code gen as much as possible. That's what the bindgen crate's min_xaml option is for:

for (def, kind) in &interfaces {
if gen.min_xaml && *kind == InterfaceKind::Base && gen.namespace.starts_with("Windows.UI.Xaml") && !def.namespace().starts_with("Windows.Foundation") {
continue;
}

But this is just a bandage to stop the bleeding. Ultimately, I'm leaning towards having a short list of excluded namespaces for the windows and windows-sys crates to reduce overall size. Developers can always use the bindgen crate to generate such excluded APIs as needed.

That's unfortunate, even if understandable. I suppose there's my motivation to move to WinUI 2 then.

Still, is this something that should be added to the FAQ, or is XAML with native code such a niche topic that only a handful of users would even ask?

The Xaml team have been silent on microsoft/microsoft-ui-xaml#2488 so it's understandable that there might be some confusion, so an FAQ entry seems appropriate. As you know, C++ struggles with Xaml for various reasons. Rust basically has all of the same issues except that its compiler is many times slower than the C++ compiler, making it even less appealing.