@feedback 楼主，你的ID为feedback也太狠了点儿吧，在我点击回复的时候还以为是程序出错了。 如你所说，我理想中的XML配置工具就是为了通过XML数据的定义，来解决界面-数据-存储三者之间的问题。现在已经能够解决了数据-存储，为什么就不能解决界面-数据呢？因为用户(开发者)只是关心数据本身，不愿意在数据之外分担太多精力，这点儿你赞同吧？ 至于能不能实现？我觉得这取决于当前的技术和设计思路。我之前有过一个比较简单的思路：根据数据类型的定义，反射出每个字段的类型信息，然后使用对应的简单控件添加到窗体中，比如提供一个文本框来让用户输入数据，如果是数字类型的，自动生成验证代码等... 难点是，如果数据的字段是自定义类型的，我目前还没有想到好的解决思路。 你可以看我插件框架里的配置工具界面，我想像中的配置工具界面就是那样的组织，但是一直没动手实践。

@无待 1.对于配置文件的来源有很多种，ini，txt，xml，Config，甚至是二进制等等。本文采用的是ini文件作为载体，所以在接口方法上定义就直接了很多，当然为了更好跟xml对接，也可以修改定义。 2.本文的界面展示就是通过反射来实现的，只是为了扩展，将界面描述为文件形式。 3.我也拜读您的文章，对于界面-数据-存储这三者之间你想仅仅通过一个xml文件来实现，我觉得这是一个很美好的理想，但需要考虑到项目的扩展性对于此种方式的风险。而我将界面-数据-存储三者分离的设计，主要是与目前项目对接和兼容将来项目的变化。

佩服楼主，不过小弟在看过这4篇文章之后有两点疑问和建议： 1.你的XML配置信息分为节点进行读写，IConfigSection的实现里，根据名称和值进行存储，这虽然能实现功能，但我感觉，这样通过字符串来读写，失去了数据自身的组织结构，是在读写字符串，不是在操作数据类。为什么不直接使用数据对象呢？ 2.在自动化配置这一块，能不能省去对界面的配置，因为我们使用XML只是用来存储数据，我们的核心是数据，XML只是一个载体，不愿意在配置界面上再花费精力，如果能根据要配置的数据直接生成配置界面(比如反射或者其它技术)，那应该更省事。 在我的blog里，也有两篇关于XML的配置，而且，我也准备在空闲的时候将它的配置界面自动化，希望交流一下。

期待下一篇

关注。

没明白为什么动态。和xml的查询差不多。

在我的笔记本上安装测试了一下。 菜单的确有点慢，估计这是由于MS在界面响应上做的处理有问题。 非常明显的感觉到鼠标从菜单上滑过时CPU占用率。 而且，还发现，这次的UI没有采用Office的CommandBar,而是重写了，这估计也是慢的原因吧。

不是说Win7运行VS2010很快的吗？

我的鼠标都是从桌子上掉下去砸坏的

VS2010太杂了,我们目前的电脑运行起来还有点不是很快,有点卡 过3年后再考虑用它了

--引用--------------------------------------------------
xc#: 唉 我之前就是用的Hook，也是无奈之举哦
--------------------------------------------------------
目前我的做法是拦截命令消息来达到目的的。

@反反复复
不好意思，我机器的版本是打了补丁的，所以才有那些dll。
esri的资源在每个dll里面，包括菜单、提示和弹出窗口，可以直接修改。

真没找到bin目录下有什么res*.dll的所谓资源文件

唉 我之前就是用的Hook，也是无奈之举哦

讲的很委婉

To:老Q
我也是，有时间交流
我用C#写的WCF,Delphi做小的客户端，就是谢谢查询等，

支持 有用

恩，在某些方面C#和Delphi没的比啊
我现在也是2个混着用，用C#写b/s，用delphi调用

--引用--------------------------------------------------
mikel: 难道楼主也混大富翁地？！

http://www.mikel.cn
http://www.tangdou.net
--------------------------------------------------------
的确，我学Delphi就是从大富翁出来的。现在也经常去滴……
--引用--------------------------------------------------
Jeffrey Zhao: 想想多少年前……好像是01年……我放弃Delphi的。
--------------------------------------------------------
为何要放弃呢？我现在还打算用Delphi开发一个小图形平台呢~

好久不用了。
d7操作OLE经常让人发疯……