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

看7楼的，很精简、明了～

这个不用讨论，因为是绝无可能的。

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

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

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

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

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

其实不用分析的，一个表的DataColChanged事件，少则有一两个，多则有几十个计算关系，代码少则几行，多则几百行，前面的Select Case也好，If Then也好，其实还有代码分段的功能，如果没有这些分段语句，所有代码混在一起，你单单凭列名，如何知道从那一行代码开始，执行到那一行代码结束？

关键是楼主的建议好不好？

同意楼主的想法，支持一下鼓励一下。

呵呵！
我不懂装懂，大家说得都有理。

我理解楼主的意思，因为foxtable只有表事件，没有列事件，这可能是为了减低复杂程度。表的任何列发生改变都必须通过表事件来处理，而表事件是通过判断来确定变化的列；而列事件只是在该列的发生变化时才触发列事件。在有些场合代码写在列事件中比在表事件中执行效率要好一些。如果有必要，老六是否考虑增加一个列事件？

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

呵呵，我也考虑过列事件，但是决大多数时候，列事件只是将代码搞得更为复杂，例如金额由数量、单价、折扣计算得出，那么同样的代码要设置在数量、单价、折扣三列的事件中，显然用表事件更为合理：

Select e.DataCol.Name
   Case "数量","单价","金额"
       e.DataRow("金额") = .....
   Case  "列1","列2"
      e.DataRow("列3") = ...
   Case  "例5"
      e.DataRow.Locked = True
End Select

这样不仅条理清晰，而且便于维护，这也是为什么最初的针对列的计算代码被删除的原因。