个人认为，C++/CLI的WinForm designer是个败笔，败就败在它非要和相应的C++/CLI代码实时对应。这样的结果就是用起来很迟钝，非常的不流畅，非常的不爽，估计就是前列腺炎的虚拟体验。增加、删除、修改control和切换窗口的时候都有明显的延迟，而且伴随硬盘动作。须知我打Day of Defeat的时候，延迟大于80ms的服务器是不会进的。我认为不是我机器配置不够，我的CPU是3800+X2，硬盘有?m的缓存，内存不多，1.5G，但是1.Visual Studio，包括Windows的cache manager，并没用把这些内存用完，2.本人的机子上没有病毒（supposedly）和防毒软件（两者并列世界上最邪恶的程序），3.本人的操作系统是小巧灵动节约资源的Windows XP（真是没想到XP也有今天，但是不出几年Vista也能得到这样的评价）。为什么怀疑这样的延迟是“和相应的C++/CLI代码实时对应”引起的呢？因为Visual Studio 6的dialog editor没有这样的功能，也没有这样的毛病，即使在性能差得多的机子上也没有可感知的延迟。忍受了如此缺陷，这个功能带来了什么好处呢？啥也没有。WinForm designer生成的代码并不好看：随着用户在WinForm designer里反复添加删除controls及其属性，生成的代码到处是乱糟糟的缩进，随机出现的空白行、accessibility modifiers。把和WinForm对应的C++/CLI代码暴露出来，是方便程序员用代码控制UI吗？比如你想把某控件的宽度设置成分辨率的函数，而不是一个常数？也不是。WinForm designer生成的代码根本不能手工修改，除非你准备从此以后再不用WinForm designer。如果你过度的修改了WinForm designer生成的代码，既便得到的代码可以编译、运行，WinForm designer也可能无法解析，而不能映射成图形，只在屏幕上留下几个exception。
基于以上的原因，当我不得不用WinForm时，我根本不以代码窗口打开WinForm designer使用的那个头文件。我会另建一个头文件，定义一个class，继承WinForm designer生成的class，然后在这个新的class搞进一步初始化，event handling之类的事。或者让Form中的controls都成为public成员，在另外的文件里用一个controller类包含这个Form类，访问相关controls，比如安装event handlers。
我希望WinForm designer在内存中用二进制的对象结构，比如一个syntax tree，记录正在被修改的Form，并将相关信息（Form衍生类的public部分）告知IntelliSense。编译的时候直接用这个二进制的对象结构生成IL代码就可以了。我不需要看到我正在编辑的WinForm的C++/CLI代码。
不知道用WinForm designer生成C#代码有没有这样的问题？有体验的读者请留下评论。谢谢。
