浅谈Access中条件表达式Criteria（二）

        在上篇文章中，我们发现Access隐藏了Criteria的求值方法，最后，我们通过将Criteria绑定到数据源的方式，完成了这一过程，Criteria满心以为Access会严守她的秘密，但是Access庞大的系统中，还是有人最后出卖了她。

　　这时候的我，就像3000年前爱琴海边的特洛伊王子帕里斯，在斯巴达王眼皮底下悄悄地带走了美丽的海伦，当我以为已经完全拥有了她的时候，却发现更多的麻烦接踵而来。

　　是否通过绑定数据源，我们就能解读一切在Access环境中合法的Criteria呢？我开始感到疑惑。在控件的“有效性规则”属性上，我止步了：

　　一个普通到不能再普通的条件表达式，摧毁了我的一切信心。这个在有效性规则、过滤器、条件格式等场合非常常见的表达式，我们却拿他束手无策。这算是哪门子表达式啊？即使海伦就在你的身边，但是语言不通也没法交流感情啊，总不可能要求我了解这爱琴海边广阔疆域内的每一种方言吧（况且，我也不喜欢说土话的女人……）

　　自己写代码来解读这类表达式显然是不现实的，除非我已经作好了写一个编译器的心理准备。相比之下，找内奸的成本还是比较低的。功夫不负有心人，我派出了“对象浏览器”这个潜入Access很久的探子，很快就有消息来报，Application类有个方法叫BuildCriteria，好像和Criteria有关，事不宜迟，立即拜访。

　　果然，BuildCriteria对Criteria很熟悉，事实上他在Access中担任着Criteria的审查工作，或者说是标准化工作。各地选派到Access总部的带着各地风俗习惯Criteria，都要通过他的审查和培训，成为一个标准的Criteria（听起来怎么有点象太监……[em06]）。这里我就不赘述BuildCriteria的职能了，这个在他的档案中有详细描述。BuildCriteria很快就提供给了我一个例子：

　　我们来看看BuildCriteria改造过后的Criteria：

　　太神奇了，BuildCriteria不但纠正了Criteria严重的地方口音，还将方言中的俗语彻底地标准化成了普通话，经过改造后的Criteria落落大方，已经可以出现在任何正式的场合。欣喜之下，我心满意足地将Criteria的绑定到一个控件上，这下，她彻底属于我了。

　　好景不长，有一天，当我临时决定回家的时候，我突然发现，她居然不在家里，更令我震惊的是，我安排在家中的三大警卫：司机BeforeUpdate、门卫AfterUpdate、贴身保镖OnChange，居然一个都不知道她去哪里了。虽然后来我知道，她只是出去逛街了而已，但是……

　　就像任何一个溺爱妻子的丈夫一样，我无时无刻不惦记着她，希望随时都能了解她在干什么，我觉得这是一种关心的表现，而现在这样她出去溜了一圈我却毫不知情的现状，是绝对不能容忍的（观众皱眉：怎么闻到一股子酸味……）。大怒之下，我把那三个警卫统统炒了鱿鱼，然后寻思着该怎么才能随时知道她在干吗（否则哪天被戴了绿帽子都不知道，哼哼……）

　　第二天我就去了Access总部参观了一下，导游首先带我浏览了条件格式的展示区，令我大开眼界的是，条件格式中的Criteria居然牢牢地受到Access系统的监视，哪怕她轻轻打了个哈欠，条件格式都灵敏地作出了反应，这不就是我想要的效果吗？但是展示归展示，当我问到如何才能对于Criteria的变化作出实时反应的时候，导游聪明地岔开了话题（这个狐狸……）

　　看来，实时监视是完全可行的，Access系统就做到了，看来ControlSource这个家伙对我还是有所保留，不能靠他了，还是要自己想办法。我突然想起了Hook这个间谍，专门喜欢往人家身上放监视器，截获人家的信件、电话，平日里向来为我所不齿，但是在这种特殊情况下，或许可以学学他的做法。

　　经过一番折腾，很快我就做出了一个简单的监视器，这个监视器的功能很简单，既然ControlSource知道Criteria在干吗，但是却只向Access汇报，却不告诉我，那么Criteria必定和ControlSource有私下的联系，我就让这个监视器监视他们之间的通讯，当然，是在不被他们发觉的情况下……

　　让我们来看看这个简单监视器的构造：

　　然后我们把这个监视器悄悄地装在Criteria身上，于是：

　　就变成了：

　　安装好一试，哈哈，果然管用。所有被监视器记录了下来