当前位置：首页 → 问答吧 → 重写MFC基类调用WPF界面

重写MFC基类调用WPF界面

时间：2011-11-27

来源：互联网

连续的通宵加班使得最近身体异常疲惫，不过好在项目即将进入尾声，能好好休息了，望大家也多多注意身体。
好了，闲话就不多说了，我来说下目前的问题。MFC的默认界面是比较难看的，又不想改代码，于是老大有了MFC和WPF结合的想法，问我是否可行。我本人是对WPF仅处于知道这个状态（穷，没用过WIN7），于是放上这个话题让大家探讨下。
1.老大的想法是重写MFC基类，绘制部分用WPF的替代(对话框以部分常用控件)，其余方法不变（不想改动工程，这是很大的工作量），问这个是否可行？
2.如果可行，麻烦列位帮忙评估一下工作量，量大那肯定是没时间去完成的。
3.如果不可行，麻烦陈述一下理由，谢谢大家。~

作者: xuddk727 发布时间: 2011-11-27

替代基类的方法完全不可行...
1）运行时环境不同，WPF是基于.NET的，MFC是传统WIN32的。前者与后者的代码完全不可能兼顾在同一个工程中，而且工程文件完全有差异。
2）可行方法之一就是将UI逻辑与功能逻辑分开成模块，所有和UI相关的界面代码采用WPF重写，然后去调用功能逻辑模块，不过调用时的参数传递之类的又得遵循.NET的调用规矩了。
3）另一可行方法，就是找个MFC的界面库美化下好了。CSDN里也有各种界面库的讨论。这个比第2）要靠谱点...工作量相对可能会少很多。

作者: dream238 发布时间: 2011-11-27

引用 1 楼 dream238 的回复:
2）可行方法之一就是将UI逻辑与功能逻辑分开成模块，所有和UI相关的界面代码采用WPF重写，然后去调用功能逻辑模块，不过调用时的参数传递之类的又得遵循.NET的调用规矩了。

的确是有这么一个可行性，但是这样做得话，当以后工程变得异常复杂的时候，那时候问题就来了，不光程序以后很难维护，而且你的工程部分有可能会遇到这么一个情况，参数不好模拟，就是在C#/C++之间进行参数传递时要把一方的参数换成另一方能认并且要一致的，如果你这样使用的话应该不难在你的工程中常发现参数有10个或者甚至更多的参数，这势必造成以后维护的困难，而且CLR的引入必定会对开发人员本身的技术来说要求更高一点.
总之，随着你工程的不断变大，程序异常的复杂，不难逃避被重写的命运。
最好是要么直接用WPF写(c#)，要么用MFC(C++)借用第三方库实现，最好不要在C#中调用C++，或者C++中调用C#，这样不是说不好，而是说不太适合相对比较复杂工程。

以上只是个人观点.说的不对的地方欢迎指出.

作者: yuucyf 发布时间: 2011-11-27

1L的仁兄，想来我的描述应该是同你2）一个意思。
我曾在论坛看到有讲述win32调用WPF的示例，想来MFC调用应该也问题不大，自然,UI和功能分离没什么关系，因为程序中并无处理PAINT，我们所需要的就是改写基类的PAINT调用WPF的方法，可惜这个我并不熟悉，想了解下这个工作量大约多大？
至于第三点已经被否决掉了，老大应该是不欲使用界面库。

作者: xuddk727 发布时间: 2011-11-27

引用 2 楼 yuucyf 的回复:

引用 1 楼 dream238 的回复:
2）可行方法之一就是将UI逻辑与功能逻辑分开成模块，所有和UI相关的界面代码采用WPF重写，然后去调用功能逻辑模块，不过调用时的参数传递之类的又得遵循.NET的调用规矩了。

的确是有这么一个可行性，但是这样做得话，当以后工程变得异常复杂的时候，那时候问题就来了，不光程序以后很难维护，而且你的工程部分有可能会遇到这么一个情况，参数不好模拟，就是在C……

这位仁兄，我以对话框基类举个例子：
我本身不会去处理继承类的onpaint（并且我以后都要求不处理），只改写cdialog基类，paint调用wpf的方法，不知道这种是否可行，若可行，工作量大约有多大？

作者: xuddk727 发布时间: 2011-11-27

买个界面库，什么都搞掂了。codejock xtreme

作者: star_luowei 发布时间: 2011-11-27

引用 5 楼 star_luowei 的回复:

买个界面库，什么都搞掂了。codejock xtreme

这位仁兄，我们老大不欲这样做，我是没有办法的，不然我何必这么费时并且绕远呢。

作者: xuddk727 发布时间: 2011-11-27

想得太简单了。MFC窗口基本上都是基于子窗口来运作的，而WPF只是一个单窗口，这不是一个PAINT替换就能搞定的。即使你替换成功，主窗口已经像WPF那么漂亮了，还是会被一大堆丑陋的子窗口覆盖。WPF是一个完整独立的UI解决方案，包括绘制、消息响应、“控件”布局、命中测试等一大堆功能，不是简单的换肤工具，如果只是为了外观好看，还不如自己写绘制代码，或者找个成熟的换肤界面库，不见得会增加多少成本（私下认为比使用WPF的学习、维护成本更低）。

实际上，楼主的问题不是技术上的问题，而是体制的问题。体制不兼容，是很难融合的。

作者: redui 发布时间: 2011-11-27

引用 7 楼 redui 的回复:

想得太简单了。MFC窗口基本上都是基于子窗口来运作的，而WPF只是一个单窗口，这不是一个PAINT替换就能搞定的。即使你替换成功，主窗口已经像WPF那么漂亮了，还是会被一大堆丑陋的子窗口覆盖。WPF是一个完整独立的UI解决方案，包括绘制、消息响应、“控件”布局、命中测试等一大堆功能，不是简单的换肤工具，如果只是为了外观好看，还不如自己写绘制代码，或者找个成熟的换肤界面库，不见得会增加多少成本（私……

我先讲讲当初为什么想如此做，第一，工程的对话框相对很简单，因为并没有处理PAINT等消息，并且绝大部分对话框只有按钮和文本控件，因此当时觉得替换相对来说成本不大，也杜绝了处理相对复杂的控件，于是想来觉得应该可以尝试一下，不过照胡大哥说的来看，WPF也是类似DUI，并不是多子窗口的，这样一来，子窗口处理就是大问题了，如此也罢，改日再试试，不行就拉倒了。

作者: xuddk727 发布时间: 2011-11-27

重写MFC基类调用WPF界面

热门阅读

热门下载