c++ - #import directive created COM wrapper classes replaces wchar_t with unsigned short -

c++ - #import directive created COM wrapper classes replaces wchar_t with unsigned short -

we have legacy code uses msxml , wrapper classes generated using visual studio's c++ #import directive so:

#import <msxml6.dll> named_guids

we upgrading project utilize wchar_t built-in type (previously, /zc:wchar_t- flag set, wchar_t unsigned short). seems cause problems type library headers generated using #import replace const wchar_t* input parameters unsigned short*.

for illustration isaxxmlreader::putproperty method has next signature:

hresult putproperty( [in] const wchar_t * pwchname, [in] variant varvalue);

but generated type library header uses next signature:

hresult isaxxmlreader::putproperty ( unsigned short * pwchname, const _variant_t & varvalue )

so not wchar_t converted unsigned short, const stripped. code fails compile without unsightly cast:

msxml2::isaxxmlreaderptr saxreader(__uuidof(msxml2::saxxmlreader60)); msxml2::imxwriterptr xmlwriter(__uuidof(msxml2::mxxmlwriter60)); //set properties on xml writer. // omitted brevity saxreader->putproperty(l"http://xml.org/sax/properties/lexical-handler", // can't convert unsigned short* (_variant_t)xmlwriter.getinterfaceptr());

is there way import directive generate proper function signatures in wrapper classes?

edit add together muddle msxml6.h header declares c++ class isaxxmlreader expected signature:

virtual hresult stdmethodcalltype putproperty( /* [in] */ const wchar_t *pwchname, /* [in] */ variant varvalue) = 0;

though after reading reply provided, guess it's hiding gory details. @ to the lowest degree it's consistent documentation (which uses header in samples.)

chris' comment has link describes problem pretty cleanly. summarize:

the problem signature of argument really unsigned short * , not const wchar_t*, despite msdn's wishful thinking contrary.

in way, signature in msdn describes moral intent of parameter, not actual signature.

the ultimate authorization on signature msxml6 type library itself. link in chris' comment describes, there no way indicate in type library argument "pointer wide character" because automation doesn't back upwards such thing. so, utilize closest thing abi-compatible, , that's unsigned short *.

the #import compiler extension can reflect what's in type library. there no way tell selectively "lie" in output.

here's actual signature of method, taken straight type library (via oleview.exe):

hresult _stdcall putproperty( [in] unsigned short* pwchname, [out, retval] variant* pvarvalue);

(there sleigh of hands in me using oleview. after all, you're looking @ output of code generator #import, doesn't quite prove new. however, best can without using type library api @ type library ourselves).

this kind of things cost have pay making com object available automation clients.

addendum:

if @ interface, have wonder how heck can perchance phone call that vb6 or vbscript. well. can't.

the saxxmlreader coclass implements 2 nearly-twin interfaces same semantics: isaxxmlreader interface we're looking at, , it's non-remotable, non-automation, c++-optimized version of interface. when utilize saxxmlreader object vb6 [default] interface ivbsaxxmlreader. idispatch-inheriting automation-compatible interface, has same semantics isaxxmlreader. wit: ivbsaxxmlreader's putproperty takes bstr instead of unsigned short *.

the msdn documentation many classes tends muddle distinction between how object called c++ , vb/vbscript. create calling same thing when that's not case, , hide interface details under rug. prefer if bit more explicit. guess have balance documenting semantics of library, , having cater both native , scripting developers, might have vastly different levels of expertise on com's plumbing.

c++ com visual-studio-2013 msxml