Morph an ActiveX control into a managed control? RRS feed

  • Question

  • We have several ActiveX controls (written in ATL C++) in our product (C# .Net). All but one do NOT have a UI and I have converted them to static libraries and embedded them in a C++/CLI wrapper. That way, our application which is launched in a browser can bring the controls to the desktop without requiring they be registered!

    However, I don't know what to do about the last one. It has a UI (Win32) that essentially looks like a big edit window. Does anyone have any suggestions as to how I can handle this one? If I strip away all the COM stuff (like the others), what do I have to leave and how would I hook it up to display in a C# windows form?

    Is this possible?

    Thanks, /steve

    Tuesday, December 20, 2011 8:49 PM

All replies

  • Hi Steve,

    Welcome to the MSDN forum.


    I think it is necessary to build the ActiveX control on COM and registry it on the machine. In this way, .NET will help you generate a wrapper of the control so that you can see the COM and use it in .NET project by "Add Reference"->"COM".

    So you can simply use the form defined in COM as using a .NET class.

    COMName.CustomForm newForm=new COMName.CustomForm();



    More information, you can refer to:

    ATL Control Containment FAQ

    Using ActiveX Controls with Windows Forms in Visual Studio .NET

    Writing ActiveX Controls in Visual Basic versus Visual C++

    Create an ActiveX control using ATL that you can use from Fox, Excel, VB6, VB.Net

    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Thursday, December 22, 2011 7:18 AM
  • Using the registry defeats the purpose. I've been working on conditionalizing out all the COM stuff - leaving a plain non-templated class. I've created a lib file with all the code but when I try to link it into a managed DLL (which I have done in simpler cases), I had to make the destructor virtual (not pure) but the linker doesn't resolve the default (only) constructor of the class:

    1>GehcTwinControl.obj : error LNK2028: unresolved token (0A00000E) "public: __thiscall CIDXWin::CIDXWin(void)" (??0CIDXWin@@$$FQAE@XZ) referenced in function "public: __clrcall GehcTwin::GehcTwinControl::GehcTwinControl(void)" (??0GehcTwinControl@GehcTwin@@$$FQ$AAM@XZ)

    1>GehcTwinControl.obj : error LNK2019: unresolved external symbol "public: __thiscall CIDXWin::CIDXWin(void)" (??0CIDXWin@@$$FQAE@XZ) referenced in function "public: __clrcall GehcTwin::GehcTwinControl::GehcTwinControl(void)" (??0GehcTwinControl@GehcTwin@@$$FQ$AAM@XZ)

    Other class methods in the same cpp file resolve fine.

    This scheme seemed to hold promise but I'm stuck here!  Ideas? (using vs2010)

    thanks, /steveA


    Saturday, December 24, 2011 2:21 PM
  • Hi Steve,


    It seems that the error happens when the C++ library is compiling. You can read the KB:

    You receive linker warnings when you build Managed Extensions for C++ DLL projects

    The dll should be linked with /NOENTRY option enabled. It should be entered using DLL exports(__declspec(dllexport)). Details steps to make it work, please refer to resolution section in the link above.


    I hope this can help you.

    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Monday, December 26, 2011 5:29 AM
  • Thanks Paul - that article helped. The declspec doesn't quite apply. A big chunk of the code is compiled (non-/clr) into an unmanaged library and then linked into a managed control. The managed control holds a pointer to the unmanaged class. One thing I have noticed is that the very first call to malloc fails (even if inside new.cpp). After that it seems to work. Quite frustrating...


    Wednesday, December 28, 2011 1:12 AM