Clarity on COM Calling Conventions and BSTR #3832
Description
Suggestion
First off, thanks for the hard work in implementing this crate. It really unlocks some powerful capabilities.
We've been recently trying to implement an Outlook COM add-in. We wrote a little about it[1], thought we understood it, and were left slightly more confused by some feedback[2] about the correct approach.
Specifically, we were trying to understand what the correct interface signature for IRibbonExtensibility is.
Our original attempt (suggested by an LLM) was the below.
impl IRibbonExtensibility_Impl for Addin_Impl {
unsafe fn GetCustomUI(&self, _ribbon_id: BSTR, out: *mut BSTR) -> HRESULT;
}
This maps (I believe) 1-to-1 with the COM C++ API here:
STDMETHOD(GetCustomUI)(BSTR RibbonID, BSTR* RibbonXml);
Problem is, unless we use std::mem::forget to forget _ribbon_id and std::ptr::write to write to out, we end up potentially destructing via Drop Outlook-owned data.
Looking at an arbitrary example, it seems some windows-rs crates get around the drop by declaring the BSTR arguments as &windows_core::BSTR. Is that the preferred mapping of GetCustomUI's arguments as well?
Please forgive any obvious oversights, as I am new to writing COM integrations, but I did want to at least ensure the blog post is correct and give some feedback from a new user of the API. I have marked this as an enhancement because I believe some documentation around it will make the crate more approachable for new users going forward.
Thanks!