我们有几个大的MFC应用程序,它们目前调用COM对象来调出复杂的对话框。我们希望将对话框集成到应用程序中 - 我们不想继续使用COM对象。
我正在调查在.NET中构建对话框作为一个单独的项目(使用Windows窗体,而不是WPF)并提供第二个C ++ / CLI项目来调用它并可以从普通的C ++代码调用的可能性。这种结构使得需要合并对话框的几个应用程序可以在其解决方案中获取项目。 (应用程序是遗留应用程序,并且无法对其进行大量重写 - 我们正在慢慢将它们转移到.NET,但这是一个多年的项目。将应用程序转换为C ++ / CLI不是一种选择。)
我已经构建了这个并从模型应用程序进行了测试,但到目前为止,我无法让它在最简单的大型应用程序中运行,并且根据我读过的一些内容,我开始了怀疑是否有可能。 (请参阅this link,尤其是。我知道this Stackoverflow question,但似乎没有相关性。)
因此。这甚至可能吗?有关如何进行的任何建议吗?
答案 0 :(得分:2)
将Windows窗体控件封装在用户控件中,并使用DDX_ManagedControl将它们嵌入到MFC应用程序中:
答案 1 :(得分:1)
您是否已成功将C ++ / CLI项目调用到.NET组件中?我会尝试缩小它无法通过的两层中的哪一层。
由于C ++代码可以调用COM组件,因此您可以使用COM支持编译.NET dll。虽然我自己没有用C ++做COM,所以我不能告诉你细节。但我已经制作了许多COM暴露的.NET DLL,并且它的这一方面相当容易。通常只是项目属性中的几个复选框(我认为在汇编选项卡中的高级按钮下)。
答案 2 :(得分:0)
你为什么需要中间人?为什么不呢
Native C++ app --> C++/CLI class library
C ++ / CLI库提供CWinFormsView或CWinFormsDialog周围的本机包装。
但是,为什么需要消除COM?这很快,一旦你擅长实现界面,仪式就不算太差了。
答案 3 :(得分:0)
我终于在一位非常优秀的Microsoft支持专家的帮助下解决了这个问题。有两个问题,一个是Boost库的线程与其默认状态下的C ++ / CLI不兼容。一种解决方案是使用不同的标志集进行编译,然后静态链接它。另一种是将它用作动态链接的DLL,这就是我最终要做的事情。
解决方案的第二部分是将链接属性中的CLR线程设置为STA,因为如果不这样做,OLE初始化将失败并显示无用的消息。