4

I have a COM dll , which is consumed by .NET applications using COM Inter-op. In one of the CoClasses , there is an Interface called IT6TrackData and it has one get property called TrackData

From the IDL file:

Interface IT6TrackData
{
   [propget, id(1)] HRESULT TrackData([out, retval] SAFEARRAY(BYTE) *pVal);
}

When the TLB file is viewed for the above IDL file, it shows the property as trackData ( t in lower case) For some reason the Client application were referring to this property as trackData and everything was working fine until now.

As part of enhancement the above Interface was upgraded to have a put property

Interface IT6TrackData
{
   [propget, id(1)] HRESULT TrackData([out, retval] SAFEARRAY(BYTE) *pVal);
   [propput, id(1)] HRESULT TrackData([in]SAFEARRAY(BYTE) pVal);
}

Now when the TLB file is viewed for the above IDL File, it show the property as TrackData ( t is in upper case), this is breaking the old .NET clients who continue to refer to the trackData with the “t” in lower case.

I have gone through this KB article http://support2.microsoft.com/kb/220137/en-gb

but is there a way out, does anyone know of a fix for this issue.

your attention is appreciated.

The IDL File

import "oaidl.idl";
import "ocidl.idl";

 [
   object,
   uuid(72867CE8-41B6-459E-A258-C7A162A26D5E),
   dual,
   nonextensible,
   helpstring("ITFST6TrackData Interface"),
   pointer_default(unique)
 ]
 interface ITFST6TrackData : IDispatch{
   [propget, id(1), helpstring("property TrackData")] HRESULT TrackData([out, retval]   SAFEARRAY(BYTE) *pVal);
   [propput, id(1), helpstring("property TrackData")] HRESULT TrackData([in]SAFEARRAY(BYTE) pVal);
};
[
   uuid(1D7ABC17-2738-4373-9B6B-239E344DBD21),
   version(1.0),
   helpstring("SampleCom 1.0 Type Library")
]
library SampleComLib
{
   importlib("stdole2.tlb");
   [
       uuid(2013CC98-47A7-468F-912A-2A2CAE25E327),
       helpstring("TFST6TrackData Class")
   ]
   coclass TFST6TrackData
   {
        [default] interface ITFST6TrackData;
   };
};
user2101801
  • 719
  • 2
  • 8
  • 20

1 Answers1

7

This is the side-effect of a hack in the type library generator built into Windows. It has a workaround for trouble caused by a case-insensitive language. Which might declare a type in one casing but refer to it elsewhere in another casing. Visual Basic is the prime example of such a language.

The hack is very crude, it takes the casing of the first identifier it encounters and then changes the casing of any subsequent identifier to match. The most typical cause of an unexpected casing change is the name of a parameter, typically spelled with a lower-case first letter. So you probably had a "trackData" method parameter in a previous version of the code.

And in your revision, either the order of the identifiers changed or you renamed or removed that parameter. Now getting "TrackData" instead.

If you have existing client code around that depends on the original casing then there's little you can do but change the casing in your source. Fugly fix, but unsurprising to your clients since they can't tell the difference :)

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • can you please explain the "Fugly Fix" as i did not understand, what i did is, changed the IDL file to use lower case of trackData, also changed the function declaration and definition in .h and .cpp respectively and rebuild, used the TLB to generate COM Inter-op dll, viewed by using ILDasm, but still the property is in Uppercase "TrackData" – user2101801 Oct 11 '14 at 09:40
  • Hehe, like that, yes. Good luck hunting the T-shark :) – Hans Passant Oct 11 '14 at 10:07
  • well i am not having any luck....i broke existing client application and that's very bad...i don't they will accept that this is a bug in microsoft – user2101801 Oct 11 '14 at 11:20
  • You give me nothing to look at. If you want another pair of eyes on it then you'll have to copy/paste the IDL into a pastebin. – Hans Passant Oct 11 '14 at 11:44
  • i have posted the IDL file, earlier version of the COM component only had the get property, when i was investigating this issue, i found that though the IDL had Upper case "T" the Oleview and Interop had lower case "t", but after my change of adding a put property, now oleview and ILDasm always show upper case T is for the both property, changing the IDL file and function declaration and definition has no effect – user2101801 Oct 11 '14 at 13:27
  • Even in the older version of the IDL, it was always in uppercase T but its the MIDL which changed it to lowercase – user2101801 Oct 11 '14 at 13:50
  • the project is very huge and there are number of IDL files getting imported, so i just put this idl as the first one to get compiled and now the trackData is in lowercase, as per the bug description "When there are two identifiers that differ only by case, the case of the second identifier is changed to reflect the case of the first" finally hunted down the T-Shark..:) .thanks very much for the help – user2101801 Oct 12 '14 at 04:25