C++ MFC的替代方案

许多投票赞成的评论声称有更好的选择。我想知道它们可能是什么

我的主要要求是UI使用本机小部件，以便我们的自动化软件能够工作。车主拉的车窗更难驾驶

我不是特别喜欢MFC的设计，所以有一个替代方案会很好。我唯一找到的是WX，这是我们已经尝试过并正在考虑放弃的。我们需要的东西不会迫使我们与一堆我们不关心的跨平台包装进行斗争。我们正在编写一个Windows应用程序，而市场营销部门对瞄准Mac或Linux一点也不在乎（是的，这也让我很伤心）

我已经稍微研究了一下.NET选项。问题是我对它了解不多，但从我能告诉你的情况来看，我们必须使用C#来获得MFC提供的许多选项。例如，乍一看，C++/CLI工具包似乎没有停靠窗口。事实上，一个直接的WinFroms选项似乎也不起作用。看起来我们不得不做一个WPF项目，而这似乎根本不是我们真正想要的（除了另一个工具包之外，我们还有大量的废话要学）。从C++中移出也需要大量的包装，我不特别喜欢我从自动包装器看到的结果。 我对.NET选项的另一个问题是，我们有一个非常密集的绘图应用程序（除了需要很多表单之外）。我知道使用诸如.NET之类的JIT语言可以得到类似的结果，但我也知道，要做到这一点，您必须更加小心。这是一个我现在不想担心的问题

另一个，也是最重要的.NET（至少是交换语言）的问题是，我们有大量的接口逻辑，虽然应该是API不可知的，但是非常用C++编写。 那么其他的选择是什么呢？这些人真的有自己的观点吗？还是他们只是大声反对那些不是他们最喜欢的语言或工具包的东西

注：
这里的问题是什么？？我特别说过，移植到其他平台甚至不是一个考虑因素，我必须有一些使用本机小部件集的东西，这样我们就不必完全改变测试用于自动化产品的所有内容！！！！有人真的看过我的问题吗？

是目前基于C++的GUI工具包唯一的真正答案（至少对于全桌面应用程序来说）。即使是纯windows应用程序，它也是值得的——它还与visual studio（获取vs加载项）进行了极好的集成，并且有很好的文档记录

wx有一些优点，一个是它在使用中非常类似于MFC，但随着Qt的发展，LGPL wx的真正优势已经丧失

编辑

---

Qt小部件不是本机的，但是它们使用本机样式API，因此如果使用默认样式，它们与本机小部件无法区分。

我已经看到Qt被广泛使用。我个人没有使用过Qt，但我看到了很多关于它的问题，远远不止wXwidgets或MFC。我想从这个开始。

MFC在它的时代还不错，但它有点老了。一个很好的例子是被更好的STL集合所取代的集合。但是你问的是GUI的东西。有一个WTL（Windows模板库），我相信它现在是开源的。与MFC相比，它占用的空间要小得多，但它的工作方式是相同的——例如，大多数类都有相同的名称和方法名称

---

在缺点方面，我发现文档相对较少，而且它似乎不适合VisualStudio向导。但这可能是我的问题-让它与VS向导一起工作对我来说非常重要。

Windows窗体与C++/CLI配合使用会很好。Windows窗体恰好也是WIN32句柄的包装器

与C++/Windows窗体相比，C#/Windows窗体的功能没有什么不同。（它们只是编译方式不同）就像你可以用C#和VB.NET做同样的事情一样

---

如果您正在寻找停靠窗口，有许多第三方库可以这样做。（有些是开源的，有些是可以购买的。）由于CLR，您可以直接包含用不同语言编写的程序集。

我的立场大致相同：大型应用程序，本机代码，前端使用MFC。我看不到任何真正令人信服的替代方案，也没有理由转向其他任何东西

话虽如此，让我提出一个意见。如果我正在做一个新的项目，需要保存/继承大量的本地代码，我会考虑尝试用一个主要的本地（C++／CLI）主应用程序来完成WPF前端。这是在VisualStudio2010中完成的，它的大部分性能都很好，所以至少是可能的。WPF有一些UI好处，而且（从自动化的角度来看）可能更容易操作和测试，因为它是CLR代码。我不确定它是否值得投资和学习曲线，但它是我考虑的一个现代纯Windows应用程序的替代品。

---

希望能有所帮助。

提供其他答案中未提及的内容：

从听起来，您需要本机控件的唯一原因是自动化软件。而需要自动化软件工作的唯一原因是测试。我假设正在使用一系列自动化测试来确保软件按预期工作

如果是这样的话，那么这里需要考虑的是：在C#/WPF领域中有一种相当流行的设计模式，称为模型-视图-模型。在这里不需要过多的细节，基本思想是您可以将实际的GUI控件（视图）从处理这些控件如何与应用程序中的其余业务逻辑交互的代码中分离出来。这段代码就是所谓的ViewModel。除此之外