Win32_Web_MsHtml missing

[ohaddahan]

Summary

Trying to add Win32_Web_MsHtml to the features result in a compilation bug.
While it's mentioned as required feature in some places:

windows-rs/crates/libs/windows/src/Windows/Win32/Web/InternetExplorer/mod.rs

Line 661 in 1facf94

#[doc = "Required features: `\"Win32_System_Com\"`, `\"Win32_Web_MsHtml\"`"]

Crate manifest

[package]
name = "windows-rs-usage"
version = "0.1.0"
edition = "2021"

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

[dependencies]

[dependencies.windows]
version = "0.52.0"
features = [
    "implement",
    "Data_Xml_Dom",
    "Win32_Security",
    "Win32_System_Performance",
    "windows-implement",
    "windows-interface",
    "Win32_Devices_HumanInterfaceDevice",
    "Win32_Foundation",
    "Win32_Globalization",
    "Win32_Graphics_Dwm",
    "Win32_Graphics_Gdi",
    "Win32_System_Com",
    "Win32_System_Com_StructuredStorage",
    "Win32_System_DataExchange",
    "Win32_System_Diagnostics_Debug",
    "Win32_System_LibraryLoader",
    "Win32_System_Memory",
    "Win32_System_Ole",
    "Win32_System_SystemServices",
    "Win32_System_Threading",
    "Win32_System_WindowsProgramming",
    "Win32_System_SystemInformation",
    "Win32_UI_Accessibility",
    "Win32_UI_Controls",
    "Win32_UI_HiDpi",
    "Win32_UI_Input_Ime",
    "Win32_UI_Input_KeyboardAndMouse",
    "Win32_UI_Input_Pointer",
    "Win32_UI_Input_Touch",
    "Win32_UI_Shell",
    "Win32_UI_TextServices",
    "Win32_UI_WindowsAndMessaging",
    "Win32_Web",
    "Win32_Web_InternetExplorer",
    "Win32_Web_MsHtml"
]

Crate code

Irrelevant.

[Nerixyz]

See #1925 (and #2348).

[riverar]

Without code, function name or an error, this bug is incomplete/invalid. Feel free to try again and we'll re-open.

[ohaddahan]

Without code, function name or an error, this bug is incomplete/invalid. Feel free to try again and we'll re-open.

Trying to compile with Win32_Web_MsHtml feature fails for missing feature, while it's still being referenced in other parts as linked.

[ohaddahan]

#1925

Not sure I fully understand, this means MsHtml isn't supported at all, or can be compiled with some flags?

[riverar]

Ah! As @Nerixyz mentioned, Win32_Web_MsHtml doesn't exist anymore.
Docs: https://microsoft.github.io/windows-docs-rs/doc/windows/Win32/Web/index.html

There was some interest in maybe generating separate bindings for this, is that something you'd need/use? (mshtml is on the way out in Windows)

[ohaddahan]

Ah! As @Nerixyz mentioned, Win32_Web_MsHtml doesn't exist anymore. Docs: https://microsoft.github.io/windows-docs-rs/doc/windows/Win32/Web/index.html

There was some interest in maybe generating separate bindings for this, is that something you'd need/use? (mshtml is on the way out in Windows)

I want to port C# code to rust.
There still is usage of Internet Explorer Server under the hood of desktop applications, hence we need it.

Some details on my trails here:

https://stackoverflow.com/questions/77847335/windows-rs-objectfromlresult?noredirect=1#comment137250059_77847335

Now I'm stuck working with COM objects, very little examples with windows-rs and I don't want to use winapi or some other older crate since this one is supposed to be the right one for the long run.

[kennykerr]

While this is sometimes useful, it is very rare. In cases like this, you can use the windows-bindgen crate to generate your own bindings and include just what you need. Something like this:

[build-dependencies.windows-bindgen]
git = "https://github.com/microsoft/windows-rs"

[dependencies.windows-core]
git = "https://github.com/microsoft/windows-rs"

And then in your build script you can simply generate what you need:

fn main() {
    println!("cargo:rerun-if-changed=build.rs");

    windows_bindgen::bindgen([
        "--out",
        "src/bindings.rs",
        "--config",
        "flatten",
        "--filter",
        "Windows.Win32.Web.InternetExplorer.IDocObjectService",
    ])
    .unwrap();
}

I used a git dependency as this relies on a bug I just recently fixed: #2785

You'll notice that this generates a lot of code, which is why it is not included by default.

[ohaddahan]

While this is sometimes useful, it is very rare. In cases like this, you can use the windows-bindgen crate to generate your own bindings and include just what you need. Something like this:

[build-dependencies.windows-bindgen]
git = "https://github.com/microsoft/windows-rs"

[dependencies.windows-core]
git = "https://github.com/microsoft/windows-rs"

And then in your build script you can simply generate what you need:

fn main() {
    println!("cargo:rerun-if-changed=build.rs");

    windows_bindgen::bindgen([
        "--out",
        "src/bindings.rs",
        "--config",
        "flatten",
        "--filter",
        "Windows.Win32.Web.InternetExplorer.IDocObjectService",
    ])
    .unwrap();
}

I used a git dependency as this relies on a bug I just recently fixed: #2785

You'll notice that this generates a lot of code, which is why it is not included by default.

Honestly, can't say that I like this. I thought the whole point of feature flags is that you use what you need only.

But the other issue, which is probably bigger (since I now you provided a solution) , is that there are very little COM object examples and I'm not sure how to proceed.

I would love to implement it and add to the examples if you can "mentor" how to get it done.

[riverar]

What are you trying to do/port?

[ohaddahan]

What are you trying to do/port?

We interact with an Internet Explorer_Server element in a GUI app , we fetch the internal HTMLDocument, run some getElemebyId , createElement calls etc.

You can see my trials at:
https://github.com/ohaddahan/windows-rs-usage

It contains a demo GUI to work on, can probably migrate that GUI to rust and have a nice real world example to be added to this repo.
A full end-to-end example, which I'll gladly open a PR with, if I can get it to work :)

[tim-weis]

there are very little COM object examples

There are several COM samples (e.g., bits or spellchecker) that cover core COM principles. Except for obtaining an initial interface pointer, there is little variance in use across APIs, which I feel is sufficiently covered.

There are, however, two common patterns that could receive some more attention:

• The IDispatch interface: Its custom protocol for discovering and calling APIs is substantially different from COM's, making it a viable candidate for dedicated treatment.
• Events in COM: This is ultimately just an application of COM with the specific challenge of picking the right LEGO® pieces and connecting them in just the right way.

Raymond Chen's A big little program: Monitoring Internet Explorer and Explorer windows, part 3: Tracking creation and destruction serves as a good starting point for deriving a sample that covers both areas.

I would feel uneasy about adding a sample based on MSHTML. While the technology has served us well for years, it is past its prime. With everyone in such a hurry these days, visitors will forget to read what's written on the tin and copy-paste the first example that doesn't immediately crash. This isn't something we should be actively supporting.

[ohaddahan]

there are very little COM object examples

There are several COM samples (e.g., bits or spellchecker) that cover core COM principles. Except for obtaining an initial interface pointer, there is little variance in use across APIs, which I feel is sufficiently covered.

There are, however, two common patterns that could receive some more attention:

• The IDispatch interface: Its custom protocol for discovering and calling APIs is substantially different from COM's, making it a viable candidate for dedicated treatment.

• Events in COM: This is ultimately just an application of COM with the specific challenge of picking the right LEGO® pieces and connecting them in just the right way.

Raymond Chen's A big little program: Monitoring Internet Explorer and Explorer windows, part 3: Tracking creation and destruction serves as a good starting point for deriving a sample that covers both areas.

I would feel uneasy about adding a sample based on MSHTML. While the technology has served us well for years, it is past its prime. With everyone in such a hurry these days, visitors will forget to read what's written on the tin and copy-paste the first example that doesn't immediately crash. This isn't something we should be actively supporting.

I have zero sentiments to MSHTML.

I just need a way to query/create elements in an embedded Explorer GUI, I don't mind using a screwdriver or a hammer as long as it works :)

I remember seeing pywinauto using Dispatch , I can see if their code can be ported to rust to achieve what I need.

[tim-weis]

I remember seeing pywinauto using Dispatch , I can see if their code can be ported to rust to achieve what I need.

@ohaddahan The IDispatch interface is really meant for scripting environments like VBScript. It's all IHTMLDocument gives you, but you can request an IHTMLDocument2 interface instead and gain access to its v-table-based call interface. That's a lot easier to use from native code.

To manipulate the DOM you probably need at least an IHTMLDocument3 interface. You can get it from either of the above interfaces.

[ohaddahan]

I remember seeing pywinauto using Dispatch , I can see if their code can be ported to rust to achieve what I need.

@ohaddahan The IDispatch interface is really meant for scripting environments like VBScript. It's all IHTMLDocument gives you, but you can request an IHTMLDocument2 interface instead and gain access to its v-table-based call interface. That's a lot easier to use from native code.

To manipulate the DOM you probably need at least an IHTMLDocument3 interface. You can get it from either of the above interfaces.

In my C# I'm using all of these (funny that the links point to MSHTML).
Which example you suggest I start to branch off from? `

[kennykerr]

Closing as there's no work for the windows-rs project, but feel free to keep the conversation going.