ActiveX control method name changing case out-of-the-blue?

I’m humming along working on an application when suddenly Visual Studio reports that it can’t find a certain property.

The property name, let’s call it SomeProperty, is a property of an ActiveX control that gets referenced from a Windows Forms 2.0 application.

So I do a clean or three assuming that an old AxInterop dll is lying around somewhere.  After the 2nd clean I blow away a few more library directories to guarantee that the control is both being created and imported from scratch.

Still no luck.  So I clean out my temp directory since Visual Studio uses the temp directory for some intermediate files and who knows, maybe a file somehow got locked or had its permissions changed.

Same error.  I pull up OleView to verify that SomeProperty really has become someProperty.  Sure enough, it shows up as someProperty.

It turns out that this is a known issue with the IDL compiler.  It uses the case of the first instance of an identifier that occurs in the IDL file for any subsequent occurrences of that identifier even when the identifier is later used in a totally different context!

In this case, I recently added a struct with a member name that happens to collide with a property of an interface defined later in the file.  Who knew that all identifiers needed to be globally unique? 

I’ll have to give the mapping thing mentioned in the KB article a try but for now I’ll leave a comment in the IDL and rename the struct member.

No comments:

Post a Comment