主题：建议：建议把DatacolChanged事件变得智能一些！

    大家都知道,表事件中用得最多、最重要的事件应该是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事件时，检测引起变化的列，自动把条件补充进去即可。

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

    贺老师现在认为不可能也没什么，但还是希望贺老师认真分析一下，即使现在没可能，现在不是很紧迫的事，或许以后您会认为有可能。几个月前我提议的您说不可能的事，后来的结果基本上都变为现实了。

    另外，我费尽心机认真写的东西被人当作笑柄其实也没什么，几个月来我的许多贴子，当时不仅被当作笑柄，而且成为许多人批评的对象，但后来的结果如何，回头看一下就不用我多说了。

    还有的老兄说，我的文笔不好，写东西太罗索，对此我不否认。但如果谁有能力无论什么事情都能用简单的几句话说清楚，那么照您的说法所有的学术论文、科研著作都可以精简为短短的几句话，所有的程序都可以用短短的几行代码来搞定。我没有这个能力，我愿意学习！

    其实发这个贴子之前，我考虑了很久，发贴之前我就知道肯定会引起争议。说实话，这个建议不是很迫切，而且，也不是必需的，没有这些改进，仍然可以实现所有的功能。但是，我之所以提这个建议，是我经过认真分析，觉得如果这样改进了，可以节约编程者大量的精力，而且还可以大大减少差错。道理很显然，在绝大多数情况下，在Datacolchanged事件中，只要知道后面的计算关系的代码，前面的条件就是确定的，从理论上来讲，这样的程序性工作完全可以用计算机来实现。如果贺老师不对系统进行改进，我们甚至可以自己对某一行编码进行处理，根据某一行没有条件的代码自动生成前面的条件代码，只不过自己编程进行处理效率会很低，也很不方便。

     前面我已经说了，这个事情既然不紧急，也不是必需，我们就暂且不讨论它吧，等到贺老师不忙的时候，再认真分析一下我的分析有无道理，有无改进的必要！

     个人认为，从使用者的角度来看，这样改进肯定会减化编程量。
     或许，对绝大多数人来讲，用不到这么复杂的计算关系，这个事件代码没有这么复杂这么长，所以也没有必要这样改进。如果贺老师还有几位老兄看一下我做的一个项目中比较复杂的计算关系，或许就会明白这样改进究竟有没有必要了。这个项目中一个DataColchanged事件中的计算关系有好几十个，代码也有数百行。无论这个事件代码我怎样组织，都会有很多重复。要么代码中有重复段，要么许多个条件中出现相同的列名，感觉这些重复应该让计算机来完成更好。
    或许，很多人没有用到计算关系这么复杂的事例，所以就不会理解我为什么这样建议，以及这样改进究竟会节约多大的工作量。不管大家是支持这个建议还是反对，我始终认为这样改进是可以实现的，而且是有必要的。回头我把更详细的东西单独发给贺老师，让贺老师进一步分析吧！

    我不主张增加列事件,在这一点上我同意贺老师的观点,如果增加列事件会使代码变更大常分散,不好管理.所以,以前的计算代码取消了,也并无不妥.  但是,其实计算代码与Datacolchanged事件中的代码相比,有一个实质性的区别.那就是计算代码完全是按变化最终影响的结果列进行组织的,而Datacolchanged事件中的条件却完全是按变化的来源列进行组织的.

     如果从计算机处理的角度来看,当然是按变化的来源列组织更为高效/方便处理,但如果从用户使用方便/容错的角度,按变化影响的结果列进行组织却更方便编程,而且不容易出错.所以,在很多时候,我很留恋以前的列计算代码,但以前的列计算代码确实太分散不易管理.我正是分析了以前的列计算代码,所以,我才认为把列计算关系的代码按变化影响的结果列进行组织应该完全是可能的(因为以前的列计算代码就是这么组织的,这已经实现了).

    对于简单的计算关系,按来源列进行组织和按结果列进行组织并无多大的区别,但对于计算关系非常复杂的事件代码,两者是有明显区别的. 一般情况下,结果列数量少,而且一目了然,很容易编码;引起变化的列却非常多,写编码时容易漏掉(我就曾不止一次的漏掉条件列).

     如果更改系统现有的Datacolchanged事件有难度,看能否这样解决.再增加一个表事件,介于以前的列计算代码与Datacolchanged事件之间,与以前的计算代码的区别在于它是一个表事件,一个表的所有代码都组织在一起;与Datacolchanged事件的区别在于,对代码不按引起变化的列进行组织,而改为按变化影响的结果列进行组织.

    增加这个事件,可能对大部分人意义并不大,但也没有不利的影响.但对于计算关系非常复杂的表代码来说,却可以提高编码效率,而且大大降低容错性.  如果表中的计算关系只有 M=A+B+C+D 这么简单,那么我的建议纯属浪费时间,但如果您认真分析一些非常复杂的计算关系,就会感觉到这两点有多大的区别了.