做了一个小的试验，一个DataGridView,一个BindingSource,然后用List<T>作实际的数据源。

当T为struct时，编辑功能失效，修改完按enter，cell里的内容立即恢复为初始值。

大致看了一下DataGridView的操作过程，

1、DataGridView用户操作的事件处理，比如按键、鼠标等;

2、DataGridView.CommitEdit方法;

3、DataGridViewCell.SetValue方法;

4、DataGridView.DataGridViewDataConnection.PushValue方法;

5、PropertyDescriptor.SetValue方法。

以前在用PropertyGrid时曾经研究过像PropertyDescriptor这一类.net设计时架构的关键元素，依稀记得对于struct与对object的处理有很大

的不同，于是试了试将T由struct改为class，再试，编辑功能正常。

没有时间研究具体原因了，以后有兴趣时再说吧，先记下。

 

从MS的几个大部头控件可以看到这向个控件背后有一个庞大的架构支撑，不过MS在介绍它们时就像介绍别的普通控件一样一寥寥数笔，实在是

令人费解，而且这个几个大部头控件的实现类相当多，不过大多为internal不为用户所见，如果不使用reflector这样的反编译工具，使用这些控件时出问题基本上是一头雾水的。

另外一点，MS的reflection API对.net framework的几个架构的支持非常重要，而reflection API基本上是目前.net程序安全的一个大问题，不知道以后MS如何处理这个矛盾（当然，从open source的角度看，这里本没有矛盾，呵呵）。

本来以为很简单的，结果费了一番周折，为了防止下次重蹈覆辙，记个笔记。

一开始的想法：

1、用impdef或dumpbin生成一个ntdll.dll的模块定义文件ntdll.def;

2、用lib /def:ntdll.def生成ntdll.lib;

3、按网上hacker给出的函数原形写个头文件ntdll.h.

结果编译时说无法链接_LdrLoadDll@16,看起来是__stdcall调用约定修饰名的原因，但是找不到办法将链接时的_LdrLoadDll@16转换到DLL实际输出的名称LdrLoadDll，查def文件格式时有EXPORTS部分的写法：

entryname[=internalname] [@ordinal [NONAME]] [PRIVATE] [DATA]

以为可以用这种方法换名，于是改def文件：

重新生成ntdll.lib后程序编译通过，但是运行提示找不到_LdrLoadDll@16入口点，看来这次反过来了，移入库里我名称对了，但还是没对应到DLL实际输出的名称。

 

想不出办法了，所以到网上搜了一下，发觉原MS在DDK提供了一个ntdll.lib，汗！

 

最后不知道从哪看到一个说自己建一个dll工程ntdll，然后生成移入库，于是试了试，自己建一个纯win32 dll项目，加一个模块定义文件:

EXPORTS

LdrLoadDll

再在程序里写一个与ntdll.dll里LdrLoadDll原型一样的空函数，编译一下，得到一个ntdll.lib，用这个编译原来的程序，编译通过，运行，

也OK了，用dumpbin看一下生成的ntdll.lib，呵呵，居然它就是用的_LdrLoadDll@16这个名字，但它却能正确的定位ntdll.dll里的LdrLoadDll，搞不明白了，为什么，lib /def:ntdll.def生成的库就不行:(

 

这方法麻烦点，不过可行，就这样吧，MS的东西，搞不明白的太多了！