3

I have a legacy OCX control built in VS2010 and used in a VB6 ActiveX EXE. When I register the debug version of the OCX and try to build it with VB6 I get the error AutoTypeNotSupportedInVB

If I register the Release version then the VB ActiveX EXE container compiles and runs. I've done online search for this error but the results are not very informative. It's not really clear if the error means it can't find the OCX type at all or if there's a type within the OCX interface that VB doesn't support. The error points to the first attempted use of the OCX object in the VB source code.

170 m_SignCaptureForm.SigPlus1.TabletComTest = False

Where SigPlus1 is the OCX object. Looking at the TypeInfo from OLE/COM Object Viewer the only differences I see between the Debug and Release are that all the BOOL return types are defined as char in the Debug version and as VARIANT_BOOL in the Release version.

========OLE/COM Object Viewer TypeInfo for Debug ========

      char TabletLCDMode;
      [id(0x00000010)            
]

=========OLE/COM Object Viewer TypeInfo for Release ========

      VARIANT_BOOL TabletLCDMode;
      [id(0x00000010)            
]

There's nothing in the OCX source code that I can see that would affect these declarations to be different in Debug vs Release. What I am asking is why I'm getting this error and if the cause is the difference in BOOL types whats the remedy for that?

ocx.h:    afx_msg BOOL GetTabletLCDMode();
ocx.cpp:  DISP_PROPERTY_EX(CSigPlusCtrl, "TabletLCDMode", GetTabletLCDMode, SetTabletLCDMode, VT_BOOL)
JonN
  • 2,498
  • 5
  • 33
  • 49
  • Do you have the debug runtime support installed? – Richard Critten Mar 21 '18 at 21:18
  • When building debug vs release versions the compiler employs different optimizations and has different error checking capabilities. Meaning that some errors may be caught in a debug build and others may be caught in a release build. If the two differ you probably have a bug somewhere. The compiler is not required to diagnose all your bugs, nor may it be able to. – Jesper Juhl Mar 21 '18 at 21:34
  • 1
    Looks like someone "#defined" `VT_BOOL` as `char` in debug mode. You can try to define it `ocx.cpp` to get the pre-processor error about redef pointing to the initial bad definition place. – Mihayl Mar 21 '18 at 21:38
  • @A.A I looked at definitions using Visual Studio with the build configuration set for Release and Debug and VT_BOOL in both configurations is an enum VARENUM with a value of 11. And BOOL in both cases is typedef int BOOL; – JonN Mar 21 '18 at 22:04
  • @JesperJuhl Yes most definitely run-time errors can occur exclusively in release or in debug build occasionally. This is a VB6 build/compile time error that is related to which OCX is currently registered. And the online documents I've found so far do not adequately define the cause of this error, nor does the error itself name or describe the Automation type that it is claiming is "not supported" Specifically is it claiming the OCX type is not found and therefore not supported or that one of the data members of the OCX type is not supported? – JonN Mar 21 '18 at 22:17
  • @RichardCritten Not sure what you mean by "debug runtime support" Is this a VB6 thing? I have Visual Basic 6.0(SP6) installed and the OCX was built in C++ with VS2010 V10.0.40219.1 SP1 Rel – JonN Mar 21 '18 at 22:38
  • @A.A Also in the OCX source code VT_BOOL is not a type but an enum with a value of 11 which the DISP_PROPERTY_EX macro uses. – JonN Mar 21 '18 at 22:43
  • 1
    Look at your ODL files and its MIDL settings for differences between Debug and Release configurations. The MFC dispatch maps are not used for the TypeLibs so the problem should not be in the cpp files. – Mihayl Mar 22 '18 at 09:49

1 Answers1

3

Following @A. A suggestion to examine the property settings for the OCX projects ODL file (SigPlus.odl) I found the solution.

There were differences in the Release vs Debug settings when looking at the Properties for the SigPlus.odl file. To access ODL properties right click on the .ODL file in the source files in Solution Explorer. The setting that was making the Debug build declare bools as char was the MkTypeLib Compatible option. The debug build had this set to No and the Release had it set to Yes. Once I changed the debug build to MkTypeLib Compatible:Yes then the TypeInfo from OLE/COM Object Viewer showed the bools as VARIANT_BOOL just like the Release build and the VB ActiveX EXE container now builds successfully.

enter image description here enter image description here

JonN
  • 2,498
  • 5
  • 33
  • 49