Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Inherited interface members are not generated for XAML controls #1715

Closed
tim-weis opened this issue Apr 26, 2022 · 3 comments
Closed

Bug: Inherited interface members are not generated for XAML controls #1715

tim-weis opened this issue Apr 26, 2022 · 3 comments
Labels
question Further information is requested

Comments

@tim-weis
Copy link
Contributor

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).

@tim-weis tim-weis added the bug Something isn't working label Apr 26, 2022
@kennykerr
Copy link
Collaborator

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.

@kennykerr kennykerr added question Further information is requested and removed bug Something isn't working labels Apr 26, 2022
@tim-weis
Copy link
Contributor Author

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?

@kennykerr
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants