大家都知道,表事件中用得最多、最重要的事件应该是Datacolchanged事件了，但很长时间一来，我一直感觉目前的这个事件用起来很别扭，最近经过认真分析，找到了问题的根源。好像目前的这个事件有点弱智，期待变得智能一些！

    在一个表中，可能一个列的变动会影响到几十列发生变化；也可能几十个列的变动，都会引起同一列发生变化。
所以，在这种情况下，我们在写Datacolchanged事件的时候，要么按引发这个事件的列（即引发事件的变化来源的列）进行组织，要么按最终影响的列（即变化引起的结果）进行组织。 若按前者（即变化源的列）进行组织，我们就需要首先对第一列变化时引起发的所有影响用代码写出来，然后再写下一列变化时引发的事件代码，依此类推……。如果这样，由于不同列变化时的代码可能有部分相同，所以会写出很多重复的代码。若按后者（即变化引发的结果）进行组织，我们就需要用条件语句把对某一列可能产生影响的所有列名列示出来，然后再写代码。这样虽然重复代码会少一些，但条件语句却很长，而且很多条件语句后面都会跟相同的列名条件。
  
    总之，之所以出现这么多的重复，原因在于目前的狐表中，写Datacolchanged事件代码的时候，需要首先用一个条件语句写明引发事件的列名（即 if e.datacol.name="XXX ")，然后才能写代码，这就导致了在这个事件中会有许多重复的代码。如果在写这个条件语句的时候，如果一不小心漏写了一个列名，即把条件写漏了，就会产生错误，应该执行的没有执行。

    举例：假如在工资表中我们要定义：应发工资=基本工资+提成+加班费+奖金，在定义这个计算关系的时候，我们还需要先定义引发这个语句执行的条件，即(if e.datacol.name="基本工资"  or e.datacol.name="提成"  or e.datacol.name="加班费"  or e.datacol.name="奖金" )。但实质上，只要确定了后面的这个公式，谁都能看出引发这个计算的列是哪4个，也就是说只要有了后面的计算关系公式，就已确定了引发这个语句的列只能是4个。这是一个确定的不会变化的内容，这样的检测最适合用程序来处理，让计算机完成既方便快捷，又不会产生错误，但狐表中非要让最适合计算机做的事情让用户手工来完成，每定义一个计算关系都首先定义引发计算的列，这样做造成的最直接的后果：一是造成了用户写很多原本应由计算机自动完成的重复的代码；二是会增大出错的可能性。
   
    我的建议是，对目前的Datacolchanged事件改进一下，不再要求必须加列名条件，即省略前面的if e.datacol.name="XXX "语句，而改为由系统自动检测每个语句与哪些列有关。还以上面的例子，按照我的建议，改进后，省略前面的条件语句，把代码直接改为：
   e.datarow("应发工资")=e.datarow("基本工资")+e.datarow("提成")+e.datarow("加班费")+e.datarow("奖金")
   然后，由系统自动判断哪些列变动时需要执行这个语句（在本例中很显然包括基本工资、提成等4列），由系统自动做这个判断，应该是很容易实现的。系统以前执行本事件时需要检测条件语句，现在改为直接检测语句，对效率应该不会有太大的影响。如果确实会影响速度，也很好解决，在保存Datacolchanged事件代码的时候，或者在系统生成dll事件时，检测引起变化的列，自动把条件补充进去即可。

    或许有人会说，在某些特殊情况下，自动生成的条件可能不一定完全正确。其实这个也不难解决，在改进后，仍然允许手工指定条件语句即可。即：若有手工输入的条件语句，按手工输入的条件语句执行。若没有条件语句，由系统自动检测引发事件的列，自动生成条件。这样即可完美的解决这个问题。

   也许我水平不够,但我认为没有必要.

似乎也有些道理，就像表达式列一样啊～  但就是因此才有了表达式列也不一定，估计难改啊～

废话太多，精简点