当前，我们维护着一套设计良好的MFC应用程序，但是用户界面开始显得疲倦，并且需要大量的代码重构来解决一些重复和/或者性能问题。我们利用许多自定义控件来处理所有自己的图形(全部使用MFC编写)。

最近，我一直在对Qt及其所带来的好处进行更多的研究(跨平台并支持我们可能称为UI开发的"更专业"外观的框架)。

我的问题是，也许转向Qt框架的最佳方法是什么？ Qt可以和MFC一起玩吗？开始将我们的某些自定义控件移植到Qt并逐渐将其越来越多地集成到我们现有的MFC应用程序中会更好吗？ (这可能吗？)。

任何建议或者以前的经验表示赞赏。

解决方案

回答

(这并不能真正回答特定问题，但是...)
我还没有亲自使用过Qt，但是对于商业Windows开发来说，它并不是免费的。

我们看过免费的wxWindows吗？不错的文章在这里。顺便说一句，如果我们想为所有平台使用一个单一的代码库，那么我们可能不得不从MFC迁移过来，我很确定(如果有错，有人会纠正)MFC仅针对Windows。

另一个选择是查看VS2008 SP1中MFC的Feature Pack更新，其中包括对新控件的访问，包括Office样式功能区控件。

回答

这是一个棘手的问题，我怀疑答案取决于我们有多少时间。如果将自定义控件移植到Qt(如果我们使用QStyle类来进行实际绘制)，则会得到更好的结果，然后我们将获得开箱即用的可主题化代码。

总的来说，我的建议是咬紧牙关，一次完成整个过程。当然，这可能需要更长的时间，但是另一种选择是花一些时间尝试调试不太协调的代码，并最终编写更多的代码来处理两个系统之间的微小不兼容性(在那做完)。

因此，总而言之，我的建议是启动一个分支，并删除所有旧的MFC代码，然后将其替换为Qt。我们将免费获得(几乎)平台独立性，尽管这需要一段时间，但最终会获得更好的产品。

最后的警告：确保我们花时间了解" Qt的做事方式"，在某些情况下，它与MFC的方法可能大不相同。代码。

回答

在我的公司中，我们目前正在使用Qt，对此感到非常满意。

我个人不需要使用MFC应用程序来使用Qt框架，但是我们可能会对这里有些兴趣：

Qt / MFC迁移框架

Qt / MFC迁移框架

它是Qt-Solutions的一部分，因此这意味着我们必须与Qt-Solutions许可证一起购买Qt许可证。 (编辑：不再)

我希望这有帮助 ！