MFC 功能包(和 VS 2010)添加了对几个“现代”GUI 元素的开箱即用支持(例如带有选项卡式文档的 MDI、功能区和带有停靠面板的 Visual Studio 风格界面) .这些对于我们这些必须支持遗留的基于 MFC 的应用程序并希望更新其外观的人来说是一个福音，并且表明 Microsoft 尚未完全放弃非托管 C++ 开发。然而，随着对 .NET、WinForms 和托管代码的大力支持(并且有很多充分的理由)，似乎没有理由在非托管 C++/MFC 中开发新的应用程序。
然后问题就变成了如何在 WinForms 应用程序中获取这些 GUI 元素。到目前为止，我发现的几乎所有附加组件和库都需要花钱，并且会引入额外的依赖项。我没有购买第三方库的预算，微软在MFC中免费提供的控件似乎足以满足我们的需求。但是我对学习MFC来开发一个新的应用程序还是有所保留的。不仅时间投入看起来很重要(从各方面来看，MFC 似乎特别难学，即使对于有经验的 .NET 开发人员也是如此——尽管我愿意尝试)，而且 MFC 的生命周期问题也被提出来了。当然，考虑到数百万行代码和用原生 C++ 编写的现有应用程序，它还会存在一段时间，但字迹似乎已经不复存在，可以这么说，它不再是微软吹捧的开发平台。
看起来这些功能现在应该可以在 WinForms 中使用，而无需第三方插件，也无需投入大量时间和资源来自定义绘图。我只是错过了什么吗？我在网上发现很少有人将 MFC 的这些新功能与 WinForms 中的可用功能进行比较，主要是因为大多数在 MFC 上编写的内容都早于其最近的更新，在此之前它看起来被认为是“过时的”，并且由于其其他缺陷，很难成为新开发的有吸引力的平台。随着 VS 2010 的最新发布，我们需要等待一段时间才能再次更新 WinForms。对于客户需要在预算内获得外观现代的 UI 的应用程序，你们采用什么方法？
最佳答案
其中大部分功能都是通过 WPF 而不是 WinForms 提供给 .NET 开发人员的。没有什么能满足您“现在应该在 WinForms 中可用”的期望，因为没有添加 WinForms。就像之前的 COM 一样，“它没有死，但已经完成了”。
我想你的问题已经有了答案。如果您正在维护 MFC 应用程序，请继续并使其看起来像 21 世纪。如果您非常了解 MFC，请继续将其用于新应用程序。如果您已切换到托管代码，并且需要学习 MFC 才能使用它，请将精力投入到学习 WPF 中。有一些“转换器”可以将 WinForms 转换为 WPF 以节省您一些时间并帮助您更快地理解 WPF - http://wf2wpf.codeplex.com/例如。
关于c# - 在 .NET WinForms 中获取 MFC 功能包 GUI 元素，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3020767/