Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Managed C++/CLI
  4. Hosting a Windows Forms Control in a MFC ActiveX control

Hosting a Windows Forms Control in a MFC ActiveX control

Scheduled Pinned Locked Moved Managed C++/CLI
csharpvisual-studiowinformscomc++
2 Posts 1 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Offline
    S Offline
    sps itsec46
    wrote on last edited by
    #1

    Hi guys, I think I need some serious painkillers on this! Short version: Can anybody explain in details how to expose a C# WinForms Control as ActiveX control. Either via hosting it in a MFC ActiveX control or by implementing it completely in C# (implementing all interfaces, registration/unregistration stuff, events). Perhaps somebody has a template project for this problem where I just can drop in my Windows Forms Control and is willing to share it with me and the others (sounds like XMas, I know). Bloody details: We have a large client application with lots of legacy code that implements an ActiveX container. So you can add e.g. GUI components by providing new ActiveX controls. Since we have almost year 2007 we want to develop new GUI components with Windows Forms instead of the existing MFC/OWL stuff (yes! OWL! :wtf:). We recently migrated to Visual Studio 2005 (.NET 2.0). As far as I can see there are 2 main approaches: (Approach 1) Use of a MFC ActiveX control for hosting the Windows Forms control and use the new MFC 8.0 template classes CWinFormsDialog[^] or CWinFormsView[^] for adding the WinForms control to a CDialog/CView. (Approach 2) Implement all necessary COM interfaces completely in C# and make them visible to COM and do the extra COM registration/unregistration stuff as explained here[^]. So the resulting component would be completely written in C# with no other languages involved. Furthermore we have about half a dozen COM interfaces for communication between the client and the ActiveX component. These interfaces must be implemented too. Sounds like very much more work than approach one. So we decided to follow approach one - hosting a WinForms control within a MFC ActiveX control. What a pain until now! This is what we did (following the MSDN

    S 1 Reply Last reply
    0
    • S sps itsec46

      Hi guys, I think I need some serious painkillers on this! Short version: Can anybody explain in details how to expose a C# WinForms Control as ActiveX control. Either via hosting it in a MFC ActiveX control or by implementing it completely in C# (implementing all interfaces, registration/unregistration stuff, events). Perhaps somebody has a template project for this problem where I just can drop in my Windows Forms Control and is willing to share it with me and the others (sounds like XMas, I know). Bloody details: We have a large client application with lots of legacy code that implements an ActiveX container. So you can add e.g. GUI components by providing new ActiveX controls. Since we have almost year 2007 we want to develop new GUI components with Windows Forms instead of the existing MFC/OWL stuff (yes! OWL! :wtf:). We recently migrated to Visual Studio 2005 (.NET 2.0). As far as I can see there are 2 main approaches: (Approach 1) Use of a MFC ActiveX control for hosting the Windows Forms control and use the new MFC 8.0 template classes CWinFormsDialog[^] or CWinFormsView[^] for adding the WinForms control to a CDialog/CView. (Approach 2) Implement all necessary COM interfaces completely in C# and make them visible to COM and do the extra COM registration/unregistration stuff as explained here[^]. So the resulting component would be completely written in C# with no other languages involved. Furthermore we have about half a dozen COM interfaces for communication between the client and the ActiveX component. These interfaces must be implemented too. Sounds like very much more work than approach one. So we decided to follow approach one - hosting a WinForms control within a MFC ActiveX control. What a pain until now! This is what we did (following the MSDN

      S Offline
      S Offline
      sps itsec46
      wrote on last edited by
      #2

      C'mon... doesn't anybody have experience with hosting WinForms controls inside MFC ActiveX controls? There must be lots of large "legacy" applications out there which implement an ActiveX container for (GUI) extensions. Any help is appreciated, even comments like "Careful, you'll likely get burned using this approach, because ..." ;)

      cheers, mykel If they give you lined paper, write the other way!

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • World
      • Users
      • Groups