VB6 Binary Compatibility Issue on public COM fields

I discovered a very interesting VB6 ActiveX DLL issue the other day when I was trying to recompile some legacy code. Every time I would recompile a particular ActiveX DLL project, the “Break compatibility” dialog would be displayed even though the public field in question did not change.

The class that was causing this issue contained a public field that referenced an OCX control. I would never recommend doing that, but doing so should not cause Binary Compatibility to break every time it is rebuilt.

Using Microsoft’s OLE/COM Object Viewer, I discovered VB6 had declared this field (i.e. its associated methods) as IDispatch rather than IPicClip. This causes consumers of the library (including the VB6 compiler) to view the field as an Object rather than a PicClip.PictureClip.

After some trial an error, my colleague and I determined that if an OCX control is going to be available to consumers of the ActiveX DLL, the OCX library must FIRST be referenced using the References dialog before adding it to the Toolbar using the Components dialog.

After adding the OCX library using the Reference dialog first, the “Binary Compatibility” dialog does not appear when rebuilding the ActiveX DLL and the class looks as expected in Microsoft’s OLE/COM Object Viewer.

NOTE: In some situations you may not be able to reference the OCX using both the References and the Components dialogs, and I would not recommend making OCX controls available using public class fields anyway.