关于本地C++,MFC应用程序调用.NET控件做显示层的方法

首先声明我是比较熟悉C++，对C#等.NET环境语言基本不懂。周末花了不少时间，收集很多相关的资料并做了一些尝试，发现这样做是可行的，有一定的实用价值。

 

 

问题来源，我发现在C++下做界面真是太痛苦了，往往分析清楚了问题，写底层的数据结构和逻辑相当顺利，但是一涉及界面，进度往往就不能很好的控制。于是觊觎.NET框架做界面的便捷性，很想尝试在本地的C++程序中通过调用.NET设计的界面部分解决我所面临的问题。

 

 

解决思路，C++/MFC界面可以做的很薄，很简单;需要用到美观界面的时候调用.NET窗体或者控件（包括.NET写的ActiveX和WPF控件），在.NET窗体或控件上操作的消息能够发回C++，这样即可形成很好的开发回路。

 

 

解决途径，为了确保开发的连贯性，主程序依旧采用非托管的MFC/Win32，因为一旦主程序改用clr编译，将出现很多无法预料的问题，并且会给项目组的其它同仁带来很多困惑，毕竟不是每个同志都有精力研究和维护两套代码。那么主程序不变的前提下，是如何兼容解决这个问题的呢？我在.NET控件，.NET窗体,WPF控件，ActiveX控件之间做了一个中间层，该层采用MFC扩展动态链接库为基础，导出函数为能够与本地MFC程序兼容的函数(导出函数内不带.NET的变量和函数)，如此一来这个中间层内部是如何完成的，用户就不需要关心了，只要知道接口函数即可打开或者内嵌dll中导出的窗体了。

 

 

解决内容：1.NET窗体，2.NET控件，3.WPF控件，4.ActiveX（这个本身没问题，这里特指用.NET框架写的ActiveX，运行时估计需要.NET Framework）。

 

 

遗留问题，1.由于我对.NET几乎一窍不通，因此消息通信和数据转换需要在今后的实践中继续摸索。这里我在做消息的时候发现C#采用的是委托(代理？术语我不太确定)的方式做的，在Managed C++中响应消息的时候发现/VC/include/msclr文件夹event.h中的委托宏定义不能解决单(多)参数的问题，这里的委托默认就是2个参数，由于某些用户自行制作的控件委托方法需要用到非2个参数的情况，我建议读者可以尝试自行扩展宏定义(扩充event.h中的宏)，千万别被它束缚（我开始不敢改，想通过其它方法完成，后来绕回来发现，扩展宏是最便捷的，也最能解决问题的）;2.由于我是基于MFC扩展动态链接库做的探索，想在上面加个窗体试试看，发现这种模式下不让我用窗体设计器（大概是M$设计上的难题），不过这个被我绕过去了，我做一个纯.NET的Managed C++工程，设计完成所需要的WinForm后，将ref myForm类复制到原工程，发现可以使用。

 

 

 

逻辑难题，1.昨晚上我在做完技术研究和编程尝试之后回过头来思考，发现这样做表面上是很方便，界面写起来很快很美观，不过重要的是主程序在逻辑上如何做到无缝，也就是说C++程序中的对象传递过来的能用性有多少？譬如我在主程序中自己定义了一个类的对象，能将对象传递到这种界面下进行调用吗？似乎是可以的，但我不能确信，毕竟用到了.NET的东西。即对应用情况我还得多总结，什么情况试用这种开发模式，各个分模块相对独立情况下应该可行。2.有对.NET非常熟悉的同事告诉我说应该倒过来，以.NET框架为主，C++模块为辅助，可惜我对.NET不熟悉。也许这样做很丑陋，如果的确是那么仅供大家参考。

 

 

希望有兴趣的朋友回帖，也许有更好的方法解决这些问题。