Question

Acoording to documentation, this property gives me a TCHAR, but when I see the source code, this is the declaration:

    [DispId(1011)]
    ushort fontName { get; }

Anyway, I don’t know how to neither get a TCHAR from a ushort or get a string from a TCHAR. Anyone?

Answer 1

I see it, you’ve got a problem. The IDL declaration is

[propget, id(DISPID_IHTMLCOMPUTEDSTYLE_FONTNAME)] HRESULT fontName([retval, out] TCHAR * p);

Well, that’s technically possible, the caller would have to pass a pointer to a buffer of TCHAR that’s large enough to store the returned string. That is massively odd though, strings are almost always handled as BSTR in COM interfaces. TCHAR* would be an accident waiting to happen when the caller doesn’t pass a buffer that’s large enough. And TCHAR will be just plain wrong when the client program is compiled without UNICODE in effect.

This has to be a bug, it should have been BSTR*. Or TCHAR**, a bit of a long shot. Another thing that’s really odd is that they assigned DispIDs to the methods but didn’t inherit the interface from IDispatch. That’s just plain pointless. I don’t think this was written by a MSFT programmer that knew what he was doing.

The type library importer would indeed have no choice but to pick ushort as the return type, there is no way for it to guess that it is actually an array of characters. There’s is no MIDL attribute on the argument that says it is an array, another thing that’s really odd and hinting that the argument really is a BSTR*. Patching the import library is technically possible, you’d have to decompile it, edit the .il and put it back together with ilasm.exe. Of course, you cannot really do this to the standard PIA, you’d have to give up on that.

No happy answers here, this is just plain wrong. Perhaps you can ping connect.microsoft.com to see what they think about it. Although they are liable to close it as “external”, in which case Microsoft Support is your only real recourse.