Cannot use implement macro

[alexiokay]

Summary

I'm tryiong to use implement macro from windows crate, but i get this error:

#[implement(IAudioEndpointVolumeCallback)]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ could not find `windows_core` in the list of imported crates

Crate manifest

[package]
name = "VortiDeck"
default-run = "VortiDeck" 
version = "0.1.0"
description = "A Tauri App"
authors = ["you"]
license = ""
repository = ""
edition = "2024"
rust-version = "1.86.0"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[lib]
name = "vortideck"
crate-type = ["staticlib", "cdylib", "rlib"]

[build-dependencies]
tauri-build = { version = "2.0.5", features = [] }

[dependencies]
serde_json = "1.0"
serde = { version = "1.0", features = ["derive"] }
log = "0.4"
tauri = { version = "2.2.5", features = ["tray-icon"] }
tauri-plugin-log = { version = "2.2.1", features = ["colored"] }
tauri-plugin-websocket = "2.3.0"

# certs = { path = "../certs"  }
pingora-reverse-proxy = { path = "../pingora-proxy-src",  features = ["proxy"]  }

tokio = { version = "1.42.0", features = ["full"] }
tokio-tungstenite = {version = "0.26.1", features = ["rustls", "native-tls"] }
tokio-rustls = "0.26.1"
rustls = "0.23.21"
rustls-pki-types = "1.10.1"
argh = "0.1.13"
rustls-pemfile = "2.2.0"
miette = {version="7.4.0", features= ["fancy"] }

thiserror = "2.0.5"
futures-channel = "0.3.31"
futures-util = "0.3.31"
tauri-plugin-shell = "2"
tracing-journald = "=0.3.1"
local-ip-address = "0.6.3"
simple-dns = "0.10.0"
mdns-sd = "0.13.1"
env_logger = "0.11.5"
qrcode = { version = "0.14.1", default-features = true }
image = "0.25.5"
base64 = "0.22.1"
platform-info = "2.0.4"
device_query = "3.0.0"
enigo = "0.3.0"
diesel = { version = "2.2.0", features = ["sqlite", "r2d2", "returning_clauses_for_sqlite_3_35"] }
diesel_migrations = "2.2.0"
dotenvy = "0.15"
tauri-plugin-store = "2"
dirs = "6.0.0"
tauri-plugin-fs = "2.2.0"
warp = "0.3.7"
diesel-derive-enum = { version = "2.1.0", features = ["sqlite"] }
tauri-plugin-process = "2"
tauri-plugin-deep-link = "2.0.0"
tauri-plugin-http = "2.3.0"
tauri-plugin-pinia = "3"
tauri-plugin-os = "2.2.1"
keyring = { version = "3.6.1", features = ["apple-native", "windows-native", "sync-secret-service"] }
reqwest = { version = "0.12.12", features = ["json", "cookies"] }
libsqlite3-sys = { version = "0.32.0", features = ["bundled"] }
pyo3 = { version = "0.24.1", features= ["auto-initialize", "abi3-py39", "generate-import-lib"] }

# MCP SERVER DEPS
rmcp = { version = "0.1", features = ["server", "transport-sse-server", "transport-io"] }

[target.'cfg(windows)'.dependencies]
winreg = "0.55.0"
windows = { version = "0.61.1", features = [
            "Win32_Foundation",
            "Win32_Media_Audio",
            "Win32_System_Com",
            "Win32_Media_Audio_Endpoints",
            "Win32_System_Com_StructuredStorage",
            "Win32_System_Variant",
            "Win32_System_Memory",
            "Win32_System_Power",
            "Win32_System_Registry"  ] }
#windows-implement = "0.60.0"


[dependencies.uuid]
version = "1.11.0"
features = [
    "v4",                # Lets you generate random UUIDs
    "fast-rng",          # Use a faster (but still sufficiently random) RNG
    "macro-diagnostics", # Enable better diagnostics for compile-time UUIDs
]

[target.'cfg(not(any(target_os = "android", target_os = "ios")))'.dependencies]
tauri-plugin-autostart = "2"
tauri-plugin-single-instance = {version = "2.2.3", features = ["deep-link"] }
tauri-plugin-updater = "2"

[target.'cfg(any(target_os = "macos", windows, target_os = "linux"))'.dependencies]
tauri-plugin-autostart = "2"

[[bin]]
name = "VortiDeck"
path = "src/main.rs"  # This is the main entry point for your Tauri app



#[target.'cfg(not(any(target_os = "android", target_arch = "wasm32")))'.dependencies.libsqlite3-sys]
#features = ["bundled"]
#version = "0.28"

Crate code

[kennykerr]

#[implement(IAudioEndpointVolumeCallback)]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ could not find `windows_core` in the list of imported crates

Did you try to add windows-core to the list of imported crates?

[Nohac]

I have the exact same issue. I'm not sure I understand the error message, doesn't the windows crate already include or re-export windows_core? Having use windows::core in the code does not help.

[kennykerr]

You need to add windows-core as a crate/cargo dependency in your Cargo.toml file. While the windows crate does depend on the windows-core crate, there is unfortunately no way for a macro like implement and interface to benefit from this indirect dependency.

Either the implement macro generates code that depends on the windows-core crate, as that's all it really needs, or it generates code that depends on the windows crate. The problem with the latter is that there are many cases where a project does not need the larger windows crate and forcing this larger dependency is undesirable.

[alexiokay]

thanks, Im stiill strugling with implement. and when using implemnt macro its complaining about struct so i used this: idk. prompted ai 20 times to fix, its getting crazy xd

Like i just want to listen to volume changes in my app from the system..

636 | impl IAudioEndpointVolumeCallback_Impl for VolumeCallback {
    |                                            ^^^^^^^^^^^^^^ the trait `IUnknownImpl` is not implemented for `VolumeCallback`

this is my code:

[cfg(target_os = "windows")]
struct VolumeCallback {
    app_handle: UnsafeCell<AppHandle>,
}

#[cfg(target_os = "windows")]
impl VolumeCallback {
    fn new(app_handle: AppHandle) -> Self {
        Self {
            app_handle: UnsafeCell::new(app_handle),
        }
    }
}



#[cfg(target_os = "windows")]
impl IAudioEndpointVolumeCallback_Impl for VolumeCallback {
    fn OnNotify(&self, pnotify: *mut AUDIO_VOLUME_NOTIFICATION_DATA) -> HRESULT {
        unsafe {
            if !pnotify.is_null() {
                let data = &*pnotify;
                let volume = data.fMasterVolume * 100.0;
                let muted = data.bMuted != 0;
                
                // Log the volume change
                println!("Volume changed (callback): {:.1}%, Muted: {}", volume, muted);
                
                // Emit a Tauri event
                let app_handle = &*self.app_handle.get();
                let _ = app_handle.emit("volume-changed", 
                    serde_json::json!({
                        "volume": volume,
                        "muted": muted
                    })
                );
            }
            HRESULT(0) // S_OK
        }
    }
}

[kennykerr]

Here's an example:

windows-rs/crates/samples/windows/bits/src/main.rs

Lines 38 to 41 in 83d4e0b

	#[implement(IBackgroundCopyCallback)]
	struct Callback;
	impl IBackgroundCopyCallback_Impl for Callback_Impl {

Notice that the interface trait "_Impl" is implemented for the implementation struct's generated "_Impl" type.

[alexiokay]

oohh. okay let me try.

edit: nah still the same;

 | impl IAudioEndpointVolumeCallback_Impl for CallbackC {
    |                                            ^^^^^^^^^ the trait `windows_core::IUnknownImpl` is not implemented for `CallbackC`
    |

and

 | #[implement(IAudioEndpointVolumeCallback)]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Endpoints::IAudioEndpointVolumeCallback_Impl` is not implemented for `CallbackC_Impl`

EDIT:

I had to add _Impl after struct name. Thank you. Solved.

[philpax]

Hi there! I'm working on a PR for cpal, which has a variable version range for windows. Because of this, there doesn't seem to be a way to depend on windows-core in such a way that it will be resolved to the same windows-core as used by windows and leave it publishable (wildcard dependencies can't be published to crates.io).

As the versions cpal depends on are already published, there's nothing windows-rs can do to help for those versions. That being said, however, would it be possible to add an argument to the implement macro that tells it to use windows::core instead of windows_core, similarly to how serde(crate) works? This should hopefully alleviate the issue in future while still preserving the lack of dependency on windows by default.

[kennykerr]

Long term, I'm trying to break up the windows-core crate so that there is less interdependency on this one crate and things like COM support can be more isolated and versioned independently with such a large ripple effect.

[riverar]

Would it be beneficial for this crate to use bindgen's recently added --specific-deps and take full control? The impact to that crate wasn't clear to me at a passing glance, but just throwing it out there!

[philpax]

Long term, I'm trying to break up the windows-core crate so that there is less interdependency on this one crate and things like COM support can be more isolated and versioned independently with such a large ripple effect.

Makes sense, but wouldn't that run into the same problem with parallel crate versioning? The macros should still be usable without having to depend on another crate.

Would it be beneficial for this crate to use bindgen's recently added --specific-deps and take full control? The impact to that crate wasn't clear to me at a passing glance, but just throwing it out there!

Hmm, I'm not sure; this is my first PR, so I don't know what the project's long-term thinking around that is, but I suspect it would be difficult to make work regardless - it relies on windows's high-level helpers, and I assume the bindgen stuff won't include the COM implementation macro.