原生 API 窗口设计器答案

【问题标题】：Native API window designer原生 API 窗口设计器
【发布时间】：2010-11-11 11:00:06
【问题描述】：

为什么 Visual Studio 中没有原生 API 表单的设计器？类似于德尔福？如果有一些程序、工具等，请指教。

在纯 API 中设计复杂窗口的最佳方法是什么？

【问题讨论】：

【解决方案1】：

有用于对话框的资源编辑器，然后是代码。我从来没有真正错过一些可视化设计工具，尽管控件本身提供更好的支持会很好。

核心问题是抽象级别： 仅使用 Win32 控件，设计复杂的 GUI 需要一些先见之明，并且这些控件都具有略微不同的怪异、功能和特性。它们没有可用于在其上构建设计器的通用界面。

WinForms 在设计之初就考虑到了对设计者的支持，这表明了这一点。 Win32 控件的主要设计问题是代码和数据的内存占用。

即使是 MFC（仍然显示出许多内存不足的迹象）也无法很好地抽象出这些奇怪的东西，以保证一个像样的表单设计师。

带有不错的表单编辑器的所有环境（我记得 Watcom ++ / Optima、ZINC 以及其他一些我忘记了名称的环境）还带有一个不错的具有高抽象级别的表单库。

那么，修改的问题就来了。设计师的输出应该是什么？一个人可以拍摄一个 XML 数据文件，但这会给您的原生应用程序添加一些大型库的依赖关系 - 没有多大意义。或者您创建代码，但 C/C++ 不太适合。另一种二进制格式？你会把自己限制在设计师允许的范围内。

最后，设计者不得不单独处理每个控件，仍然无法让您完全了解控件和窗口机制。当 C++ 是大规模桌面开发的首选时，它从未被采用过。现在添加它，当有 - 可以说 - 更好的选择时，将是一个相当愚蠢的举动。

【讨论】：

感谢您的评论 :) 同意。为什么它从未完成，更多的是我想知道的。为什么 MS 不能在 Delphi 中实现类似于 VCL 的东西？
如前所述，MFC 过去和现在都不再适合纯 Win32。也许他们意识到，使用 MFC 和 ATL，他们已经在 UI 框架上投入了足够多的资金，以至于无法处理同一级别的第三个分支。从业务角度来看，将资源放入 .NET 可能是一个不错的决定。但这只是猜测。

【解决方案2】：

这可能是因为在 WinAPI 中没有标准的控件布局方式，您必须自己管理它。 WinAPI 中没有基本的“控制”类 - 一切都是某种窗口，因此无法通过通用布局编辑器/设计器支持它们的差异。

但是，您可以在对话框中创建窗口布局，并自行调整其大小或使用 codeproject 上发布的方法（this 或 this - 两者都与 MFC 相关，但这很容易翻译）。

或调整ScreenLib 以适应您的桌面需求。

【讨论】：

【解决方案3】：

这是因为微软。他们已经转向 dotNet 和 C#。 Visual Studio 2005 为这些提供了不错的 GUI 编辑器。为什么需要使用纯 API？

【讨论】：