标签：开发框架

框架的最终目的，是提供一个明确定义的地方，将对象的属性和行为可以放置在这里，用于将来的项目开发。控件是一个主要的例子，因为它们没有内建类（built-in class），而我们想扩展它们的功能。于是，我们为每个控件类型创建了类，这样我们就能扩展这个控件的功能。

为了这个目的，在本系列中，我们将为已创建的组合框控件类添加一些新的功能。这个新功能就是从属对象重新查询（dependent object re-query）。

从属对象重新查询的意思就是，我们某个类对象创建一个方法，当该类对象的值有变化时，任何从属于该类对象的对象的值，都会执行重新查询，获得更新。在本系列中，这个类对象就是组合框控件类。当用户在组合框控件中选择了一个新的值，任何从属于这个组合框控件的对象会自动的重新查询，基于组合框控件的值，更新自己的筛选数据。

这样的行为通常是非常有用的，同时也能向我们展示，如果我们想让框架做更多的事情的话，我们应该如何在其中添加新的事物，从而扩展我们的框架。

从属对象

从属对象在Access应用程序中是很普遍的。举个例子，有一个窗体，上面有2个组合框，名字分别为cboCompany和cboEmployees。当用户选择cboCompany的值后，cboEmployees需要重新查询自己的可选数据，只显示公司为组合框控件cboCompany中的值的员工数据。

从属对象的功能在通常情况下是怎样实现的呢？一般是为从属对象创建一个查询，这个查询为该从属对象提供数据，在该查询中，有一个字段，该字段引用了被从属的对象的值。换句话说，cboEmployees的“row source”属性（译者注：我用的英文版本Access，该属性对应的中文名称可能是“行来源”）中的查询会设置类似于“Like form!frmMyForm!cboCompany”这样的筛选条件。控件cboEmployees是从属于（依赖于）控件cboCompany的。仅仅这样做好设置以后，当你修改cboCompany的值以后，你会发现cboEmployee的值并未立即发生更新，你必须手动刷新（或通过代码）窗体，从属的组合框控件才会更新。

为了在我们的框架中实现这种功能。我们可以简单的直接在控件类中添加一个从属对象集，然后为每一个控件类添加方法，以便可被添加到这个集合中，当控件类对象销毁之前，将其从集合中移除。当然我们也会添加一个重新查询的方法，遍历集合中的所有对象，调用每个对象的重新查询方法。注意，这隐含着一个意思，每个可从属于其他控件的控件必须有一个公用的重新查询方法。

本章相关代码示例文件8.1 从属对象。

从属对象代码

从属对象的代码大概是这个样子的：

在每个控件类的开始部分（为了方便阅读，剥离了所有的错误处理代码）

在每个控件类初始化事件中，将集合对象实例化。

在每个控件类的Term()方法中写入清除代码

最后，公用函数或方法来处理从属对象的相关事情：

用这种方法，当然，不会有任何问题。但是，如果我们从类的角度，来思考这个问题的话，我们完全有更好的方案。我们可以创建一个从属对象类，将相关的代码都放置其中，然后我们只需要在每个控件类中添加一个从属类对象。

使用一个专用的类来处理这个问题的最大的好处，就是我们可以把所有类似的代码都放在一个地方——类中，然后在我们需要的地方，定义一个clsDepObj对象，然后调用类的方法。我们不再需要在每个控件中都重复去维护那一堆相似的代码。

每个控件类代码

创建了从属对象类clsDepObj，在控件类中，我们不再需要上述代码了，我们只需要这些：

在每个控件类的开始部分（为了方便阅读，剥离了所有的错误处理代码）

在每个控件类初始化事件中，将从属类对象实例化。

在每个控件类的Term()方法中写入清除代码

然后创建一个属性来获取从属类对象的指针（句柄/引用）

你不得不承认，相比将整个从属类的代码都添加在到每一个控件类中来说，在每个控件类中只用添加这些行，要来的更加清晰和容易。更不必说，如果我们想添加一些其他的从属对象功能到框架中来的话，我们只需要在一个地方添加即可，而不必在每个控件类中都做一遍。

有一件事情我们必须要记住，在每个包含从属对象的控件类中，要添加一个重新查询的方法。显而易见，如果这个控件类有一个数据源，那么我们需要重新查询这个控件，也需要调用从属对象类的重新查询方法。

最后，当组合框的AfterUpdate（更新后）事件被触发后，我们想重新查询新类的从属对象集合中所有的对象。我们通过调用mclsDepObj的重新查询方法就可以了。WithEvents！你将会爱上它。

现在，我们有了这个新的类和它的功能，我们怎样告诉框架来使用它呢？答案就在窗体类的初始化的地方——窗体的Open事件。

窗体的内建类

我修改了frmPeople11窗体，添加了2个组合框控件在窗体的头部，cboCompany和cboEmployee，分别包含公司和和这些公司的员工。窗体的代码大概是这样子的：

我们的自定义窗体类dclsFrm

以及窗体的打开事件

我知道这看起来非常复杂，但是我们可以一步一步来看，我会告诉你每一步是在干什么。Set语句和Init语句跟以前是一样的。我们将指向窗体内建类的指针（Me）和指向窗体本身的指针（Me）传递给fdclsFrm对象。非常凑巧的是，对窗体来讲，Me既代表了窗体内建类，也代表了物理窗体，所以出现2个Me，看起来有点奇怪。

接下来，我们用一个With语句来加快我们获取dclsFrm对象内部内容的速度

dclsFrm有一个Children属性，可以返回类的集合指针。有了这个，我们现在可以引用集合的属性和方法。我们使用.Item()方法从集合中返回一些东西。

还记得吗？在dclsFrm类中，我们有一个控件扫描方法，可以发现窗体上的所有控件，然后为每个控件创建一个对象，然后将该对象的指针保存在集合colChildren中。还记得我们使用什么作为主键吗？是的，我们使用了控件的名字。这样一来，.Item(“cboCompany”)告诉类对象在集合colChildren中返回名叫“cboCompany”的对象，换句话说，就是控件cboCompany的控件类对象。

这样的话，.Item(“CboCompany”)就是指向组合框类对象的指针，与下述语句是一样的：

既然我们有了指向组合框控件类对象的指针，我们就可以调用这个类对象的任何方法或属性了，这就有了下面的语句：

代码的意思就是，对组合框控件cboCompany的控件类对象来讲，调用它的从属类方法clsDepObj，返回指向它的从属类对象的指针，然后调用从属类对象的Add方法，准备添加一个从属类对象。

记住，句点符号指示那个类的属性或方法，这样一层一层的引用，有点像魔术师的盒子，大盒子放着中盒子，中盒子中放着小盒子，一直到我们最终要引用的对象。

fdclsFrm.Children.Item(“class name”).clsDepObj.Add

顺便说一下，我们可以在这行上面设置一个断点，然后单步调试这段代码，观察各种类的方法的调用情况，返回的指针指向下一个对象，然后调用下一个对象的方法，返回下下一个对象等，一直到最后，我们钻入到最后的Add方法。

这非常有趣！

好了，让我们回到主题。

我们已经告诉dclsFrm要添加一些东西到clsDepObj。“一些东西”就是组合框控件cboEmployee的类对象。

类似的，我让窗体本身也从属与组合框控件cboCompany，所以我们也需要告诉cboCompany，dclsFrm也是一个从属对象。

最后，我们还需要重新查询cboCompany，以便它能重新查询它的从属对象。

引用窗体的Children集合对象，找到为cboCompany创建的对象，适用其clsDepObj的方法获取从属对象的引用，使用从属对象的Add方法，添加一个从属对象到从属对象集中。被添加的对象是cboEmployee的类对象和窗体本身，fdclsFrm。一旦我们将这两个项目添加到从属对象集中，重新查询整个结构。

我非常清楚，当你第一看到这些东西的时候，你肯定是眼花缭乱的。但是，请相信我，一旦你使用了类，方法，属性和集合一段时间后，这会变成你的第二天性。

总结

通过添加一个新的，只有一个集合变量，和几个公用方法的小的类，我们创建了一个操控从属对象的方法。一旦类创建好，每个需要从属对象功能的控件类，只需要添加几行代码就可以了。很有可能，最大的难点，是在窗体打开事件中，需要找到正确的控件，引用到它的从属对象，然后添加该控件的从属对象。这两个从属对象分别是cboEmployee和窗体本身。

最后的结果就是，当窗体被打开以后，没有任何记录显示出来，因为公司还没有选择，而窗体的绑定数据源中，公司作为了筛选条件。一旦我们选择了一个公司，公司组合框控件就有了值，这个值就可以用来筛选窗体和组合框控件cboEmployee。因为cboCompany会调用它的从属对象clsDepObj的重新查询方法Requery，窗体的类会重新查询窗体本身，cboEmployee的控件类会重新查询cboEmployee。顺便说一下，如果cboEmployee也被编码了，拥有自己的从属对象，cboEmployee的类对象也会重新查询它所有的从属对象，整个过程，就想波纹一样，自动的一环套一环的执行下去。

类是非常强大的工具，允许我们将功能封装在一个地方，将所有的实现必要的行为相关的变量和代码封装在一个位置，如果有必要的话，我们只需要到这个地方修改或添加新的功能。你可以将这个独立的类放到你自己的框架中，只需要相对少的功夫，就能为你自己的组合框和其他控件添加从属对象功能。从属对象处理是非常小而琐碎的功能，但是想象一下，如果类拥有十几个属性和方法会有会怎样？封装性和可移植行成为了学习使用类的首要原因。

译者注：本章介绍的从属对象非常不好理解，要搞清楚三点，一是，谁是从属对象（cboEmployee，fdclsFrm），谁是被从属对象（cboComanpy），被从属对象的变化会导致从属对象的变化。第二点是要知道如何设置窗体的绑定数据，以及组合框控件的绑定数据源，当然Access比较基础的知识。最后一点是，要了解，如果没有本章介绍的从属对象，那些在绑定的数据源中引用了被从属控件值的窗体，在被从属控件值更新后，会自动获得更新吗？答案当然是否定的。

最后，我做了这个示例文件8.1 从属对象，在该示例文件中，有3个窗体：frmPeople10，frmPeople11，frmPeople12，分别演示了未应用任何从属对象类的情况，为cboCompany添加了从属对象，为cboCompany和cboEmployee都添加了从属对象的情况。读者可以分别测试一下，看看效果差别在哪里。

后记：翻译到此章的时候，一直萦绕在我脑中的一个疑问有了一个答案。还是那个比较恼人的对象卸载问题。按照Colby的类模板的要求，对象在卸载自己的时候，首先卸载自己colChildren中的子对象，卸载子对象前，先执行子对象的Term()方法。问题来了：很显然，本章介绍的clsDepObj中的集合mcolDepObj中的对象，肯定都不是由其父对象dclsCtlComboBox所实例化，当卸载clsDepObj的时候，也需要执行它的集合中的子对象的Term()方法吗？答案当然是否定的。那么什么时候执行子对象的Term()方法？什么时候不用执行呢？

大家可以注意到，我在类模板的最后，添加了下面一个私有方法。什么时候执行Term()，由子对象的父对象是否是当前对象来决定。因为每个对象的父对象只有一个，就是实例化自己的对象。

相应的，重写后的每个类中，都有类似的代码。这样就解决了，什么时候该释放类，什么时候只是清除其指针的问题。

Colby自始至终都未曾论述过这个问题，相反，他创建了一个叫做实例堆的类clsInstanceStack（后续系列中会谈到），这个类用通俗的话来讲，就是对象的生死簿。主要用来做故障查询和除错用的。个人觉得，如果不把问题的根源找到，而只是在出现问题的时候，再来调试查错，还是于事无补的。

对象由谁实例化的，谁就是这个对象的父对象，这个对象的销毁也必须由其父对象来完成，其他的类对象，如果在其子集中引用了该类对象，那么只能在其子集中清除引用指针就好了。总结成一句话，谁创造的，谁才能毁灭。

终于，我们到了该要面对类模板的时候。为了让类提供故障排查工具，和调试帮助的功能，我们需要为类添加统一的接口（Interface）。如果你记得系列之三——集合、类和垃圾回收中，我讨论过类的一些问题，特别是那些引用窗体和控件的类。除非非常小心仔细，我们可能会在卸载类的时候遇到麻烦，从而导致内存泄露，甚至Access都无法关闭。现在是时候好好讨论这些问题了。

这里，请大家保持更多的耐心，我真的不想因为要讨论的这些问题和代码，失去任何读者。但是我知道你确实需要一点时间来适应这些内容。

我将讨论一个叫模板的类（Template class）, 我们以后创建的任何新的类都将复制这个模板类，所有的必要的接口结构都在这里，然后粘贴到新的地方，作为建立新类的基础，并在该基础上添加新类特有的部分。你可以在示例文件7.1类模板中看到模板类的所有代码。

模块注释和开头部分（Header）

我们要做的第一件事情，是为类添加一个标准的头部注释，我将一些常见的信息放在里面，比如类的作者、创建日期、版权信息等。这个区域用来为这个类做注释，解释类的一些行为，这个类的是用来做什么的，以及一些其他的你想放在此处的说明。帮助你自己一周之后再回来看到这个类时，能很快想起来你做了什么。

在这之后，我为常量和变量添加了标准的代码块结构，以及一些预定义的常量。

常量mcblnDebugPrint是一个开关，用来决定是否将本模块中的调试语句打印到立即窗口。为此，我们将调用一个名为assDebugPrint的函数，而不是直接使用Debug.Print语句。我们将这个常量传递给这个函数，函数根据常量的值来决定是否将调试语句打印到立即窗口。如果将常量mcblnDebugPrint设置为True，那么本模块中的所有调试语句都将打印到立即窗口；如果设置为False的话，就不会打印。

另外一个常量mcstrModuleName将类模块在数据库窗口，模块项下的名字明文存储起来。（译者注：获取类名还有另外一种简便的方式TypeName(Me)，不知道原作者为何不用这种方式，当然使用前“Me”必须已经被实例化了。）

接下来是类的变量声明：

此刻，我们也需要讨论一下，我们用来“自动”创建和销毁类的一些过程，毕竟，这个模板类的整个开头部分就是用来做这个的。你将在这儿添加自己的变量，但是到目前为止，你看到的内容都是框架的接口。

类很少单独存在于框架之中。类经常使用子类，子类也经常有它们自己的子类。窗体类dclsFrm就是一个很好的例子，dclsFrm可以使用组合框类dclsCbo，组合框类dclsCbo可能会使用从属类dclsDepObj（下一系列将介绍）。非常明显，窗体类可能会通过控件扫描函数，实例化一打控件类，这些指向控件类对象的指针被保存在集合中。一个组合框可能有一个或多个从属类对象，以便基于组合框的值，筛选自己的数据，如此一来，组合框控件就有了从属类dclsDepObj，该从属类对象保存的指针指向那些从属于该组合框的控件。

所有这些使用类的类，祈求有一个统一的接口界面。这样，每一个类都把指向自己父类的指针保存到mobjParent对象变量中。

dclsFrm是dclsCbo对象的父对象。dclsCbo是dclsDepObj的父对象。窗体将“Me”传递给dclsFrm，dclsFrm将“Me”传递给dclsCbo，DclsCbo将“Me”传递给dclsDepObj等等。“Me”在这三种情况下都是指向当前类的指针。“Me”在窗体里，指的就是窗体的内建类（built-in class），“Me”在dclsFrm里，指的就是dclsFrm的实例。

通过向子类传递一个指向父对象的指针，任何子类都能获得它需要的父对象的任何属性和方法。实际上，为父对象添加的一些属性和方法，可能就是用于子类调用的。

此外，每个类都有一个子集合，我们命名它为mcolChildren。mcolChildren保存了指向子对象的指针。

类的实例名mstrInstranceName是根据模块名mcstrModuleName和其他信息组成。我最后选择了“线性命名”的方法，也就是说，每个类使用它的父类的名字加上它自己的名字。这种方法使得我们非常容易的知道任何一个给定的类名具体代表什么。

最后，还有一个简单的名字变量

当类被保存在它的父对象的子集合中时，这个简单的名字变量将通常作为关键字来使用。换句话来说，类总是被存储在它的父对象的子集合中，这样，当父对象被卸载清除的时候，父对象就能清除掉它所有的子对象。集合中用作关键字的，通常是象控件名那样简单的名字。我们这样做是为了方便使用一些可用的信息（比如控件名）来索引到这对象。

 

常量和变量声明

我喜欢将开头部分的内容组织起来，让所有常量都在一起，然后是所有的变量，再然后是类可能需要抛出的自定义的事件。如果一个类变得非常复杂之后，将功能性的信息片段组合在一起，这样做应该会更方便查找一些。总的来说，这是关于组织和有条理的编写代码的方法选择，只要你按照一定的规则去编码，总会比那些没有规则的编码方式要好得多。

 

类的实例化和卸载

接下来，我将类的开头部分定义的所有对象的实例化语句都放入了类的初始化事件Initialize中。Initialize是类的两个固有事件之一（另一个事件是Terminate）。当Set语句实例化类，Initialize事件就被触发了，类就开始在内存中加载自己。

Init()通常是类被调用的第一个方法，我们在这里将类的父对象传递进来，换句话说，将哪个对象实例化了该类，那么该对象就是该类的父对象，将父对象传递进来后，类对象与父类对象的链接就形成了。

当指向类的最后一个指针被设置为Nothing时，类的卸载事件Terminate就被触发了。

Term()是类的一个方法，它通常是被父对象（实例化类的对象）的清除代码所调用。例如，dclsFrm为每个控件实例化了一个控件类（dclsCtlTextBox），将指向这些控件类的指针保存在子集（mcolChildren）中。当窗体关闭的时候，dclsFrm将遍历这个子集，调用每个控件类的Term方法，然后将控件类的指针从子集中删除。

同时，我也在类的Terminate事件中调用Term方法。任何情况下，当最后一个指向类对象的指针被设置为Nothing的时候，该类对象将自动卸载。这样，理论上来讲，只用将指向类的指针设置为Nothing，类的Terminate事件就会被触发，然后事件代码中的Term方法就被执行了。

这看起来有点“重复工作”了。是的，一点没错。我之所以这样做，是因为在一些情况下，我们很有可能为类对象设置了一个指向其自身引用（Set mobjParent=Me），这样一来，在类对象内部，就永远有一个指向该类对象的指针。如果我在其他类中也有一个指向该类对象的指针，然后我将这个指针设置为Nothing，然后，发现了吗？这个类对象根本不会被释放，因为还存在最后一个指向它的指针，位于它的开头部分（mobjParent）。然而，如果我调用Term方法，我就将它所有保存的指针清除掉了，指向自身的指针也被清除掉了，这样，当我将外部的指向该类对象的指针设置为Nothing的时候，类对象就能正常的被卸载了！

这种情况虽然只是偶尔出现，但是只要有出现的可能，为了保险起见，还是调用类的Term()方法，然后设置类对象的指针为Nothing，触发类的Terminate事件，Term()被再次调用。我们可以设置一个静态变量来帮我们记录Term()方法是否已经被执行，这样我们就不用多次运行。

（译者注：原作者对“重复工作”的解释，存在疑点。如果一个类对象的mobjParent指向其自身，则必须“显式”调用Term方法，才能将该指针清除，Terminate事件中的Term代码是执行不了的，因为类对象的最后一个指针并未清除。对“重复工作”合理的解释，应该是：在不存在环形引用的情况下，如果类的使用者未按照约定的方式去销毁类对象，也即并未先执行Term，而直接Set类对象的最后一个指针为Nothing，类对象的Terminate事件被触发，Term被调用，清除类对象的子集中的子对象。若不在Terminate事件中调用Term，会导致子对象无法被清除。）

 

标准属性和方法

我们已经讨论了开头部分和类的实例化和卸载接口，接下来，我们要讨论标准的属性和方法。显然，我们需要让其他类（或者其他开发者）获得开头部分的数据。模块名ModuleName，实例名InstanceName，以及普通的名字Name，这些都需要作为类的属性，给到类的使用者读取。为了在编码时，智能感知窗口能将这些属性组织在一起，我将Name放在了属性名的前面。

最后，我们还需要有获取父对象和子集的属性。

以上就是框架类模板的全部代码。框架中的每一个类都包含上述所有代码，这样才能给我们一个非常标准的编程界面，我称之为框架接口。这些与框架相关的代码与类要实现的功能几乎是没有任何关系的，它存在的唯一目的，就是让我们以一个标准的方式来创建和销毁类对象。

如果一个类不能被卸载掉，在某种情况下，会导致Access程序无法关闭退出，从这一点上来讲，框架接口设计所发挥的作用就变得非常关键。

类的功能代码

最后是类的功能代码部分。我觉得用以下的结构去安排，会更加有组织一点。我喜欢将相似的事物放到一起，当然，每个人都有自己喜欢的方式，这取决于各自的想法。是否参照，取决于你自己。

将框架类接口应用到已有的类上

我将会按照上面介绍的框架接口的标准，修改以前系列中创建的所有的类。我们需要花一点时间来适应类中的这些框架接口相关的代码。

总结

框架变得更加复杂了，框架中有很多类，类会实例化其他的类，在子集合中创建自己的子对象，子对象又可能会实例化子子对象，形成一条对象链。类对象销毁自己的时候，先会销毁自己的子集合中的子类对象，子类对象被销毁前，会先销毁子子类对象，子子类对象销毁自己前，会。。。。。。你看懂了吗？类对象销毁时，销毁的是一整条对象链。为了让类对象按照这个逻辑来创建和销毁自己，我们必须有一个系统上的安排，让它来帮助我们自动做到这一点，否则，我们将陷入混乱不堪的局面。本系列所讲的所有内容，就是尝试去标准化类的创建和销毁，以一种我们可以依靠的相同方式，不管我们实例化的是什么类。

在系列之四中，我们讨论了为什么要使用类，也看到了文本框背景色自动变化的示例，从繁琐的方法：运行窗体本地代码（frmPeople1）；到更简洁的方法：为文本框创建控件类。我们看到控件类在窗体的头部被定义，然后直接初始化（frmPeople2），或者使用类工厂（class factory）函数初始化（frmPeople3/4）。为了进一步简化窗体代码，现在让我们来了解一下我称之为“监管类”（supervisor class）的类。

监管类是指加载和管理其他类的类。

注意到没有？系列之四中，窗体的内建类（built in class）为创建这些控件类做了很多工作。当我们添加新的控件类，比如组合框，复选框等，情况只会变得更加糟糕，如果每个控件类型都有50个实例的话，事情会变得不可想象的复杂。我们在frmPeople4中看到的所有代码都不得不在任何你想实现类似功能的窗体中不断重复出现。我们需要创建一个我们自己的窗体类，将这些创建控件类的代码都放在里面。然后我们只需要在每个窗体中创建和销毁这个监管类。本质上来讲，我们所做的，不过是将窗体中的代码转移到一个类中，用名为Init()和Term()的方法，来创建和销毁我们的新窗体类。

好了，新类dclsFrm（窗体类）的代码可以在示例文件中看到5.1监管类示例。

监管类 dclsFrm 代码

现在我们应该对类的头部有点熟悉了。在这里，我们定义了集合变量mcolClasses和窗体变量mfrm，集合变量用来存储控件类的实例，比如dclsCtlTextBox。mfrm用来保存指向实际窗体的指针。

所有的类都有Initialize事件，当类被实例化的时候，该事件会自动执行。我使用Initialize事件来初始化类要用到的所有对象。mcolClasses集合对象，是该类用来存放所有控件对象的容器，在使用之前，必须将其实例化。但是，Initialize事件是不能带有任何参数的，而类初始化的时候，需要传入一些参数才能配置好它的功能。所以我使用了名为Init()方法。Init()将传入的指向窗体的指针保存在本地变量中。现在我们有了一个指向窗体的变量，所以我们可以调用FindControls来遍历窗体的控件集，然后加载控件类。

在上一系列中，我们使用的是ClassFactory来为控件创建我们的类对象，在这里的FindControls中，我们进一步简化了代码。这个子例程遍历窗体上的所有控件。它检查每个控件的控件类型，然后根据控件类型，为每个控件实例化一个相应的对象（目前我们只为文本框创建了类，所以这里我们只为文本框控件实例化对象。我们很快就会为组合框，复选框，列表框等更多的控件创建类。）这个例程也将相应的为这些控件类型实例化对象。

Initialize事件是在类被实例化的时候自动运行，对应的，Terminate事件会在类对象被销毁的时候自动运行。在Terminate事件中，直接调用Term例程。Term例程先通过例程ClsDestroy销毁集合对象mcolClasses中的所有对象，然后释放窗体指针。

译者注：在这里，为什么不直接将Term例程中的代码写到Terminate事件中呢？根源在于环形引用问题。对于环形引用情况来讲，必须先将类中参与环形引用的对象（mfrm），释放其指向类外部对象（一个真实的窗体）的指针，变成单向引用后，类（dclsFrm）对象才能被顺利释放掉，Terminate事件才会被执行。

我们可以将一个类中使用到的所有对象分成2种，第1种是参与环形引用的对象，第2种才是普通的非环形引用的对象。只有第2种才能放在Terminate事件中。而第1种要在解除环形引用后，类才能被正确销毁，Terminate事件才会发生。

在类的实际设计中，区分这2种情况需要花费更多的精力，为了简便起见，选择了不去区分，全部视为第1种情况。在释放类（dclsFrm）对象之前，首先运行Term方法（注意到Term方法为Public没有？），先将类中使用的对象全部销毁，然后再销毁类对象本身。

这样一来，Terminate事件好像就没有了存在的必要了。在这里还是保留它，在Terminate事件中调用Term方法，这样做一是为了统一起见，二是为了防止用户在使用类时，忘记了调用Term方法，而直接释放了类对象。毕竟重复释放类中使用的（包含的）对象并不是一件坏事。

类的私有例程ClsDestory遍历类的集合变量mcolClasses中的所有的控件类实例，首先运行该对象的Term方法，然后将其销毁。最后将集合变量本身mcolClasses也销毁了。

窗体的内建类（built in class）代码

dclsFrm这个类应该如何使用呢？现在，我们来看看实际窗体中的代码。（参见frmPeople55.1监管类示例）

在窗体的头部，我们定义了一个类型为dclsFrm的变量fdclsFrm。然后在窗体的Open事件中，将其实例化，最后将窗体本身（Me，Me只能在类中使用，指代该类的实例本身。）作为参数传递给dclsFrm类的Init方法。最后在我们关闭窗体的时候，先调用dcldFrm类的Term方法，然后销毁fdclsFrm对象。

如果你记得上一系列中窗体内建类中处理控件的代码（在frmPeople4中），你会发现，这个窗体（frmPeople5）中的代码大大的减少了。而且更有意思的是，如果我们在窗体上再继续增加100个文本框，我们一行代码都不需要增加！现在，你可以在窗体内建类中写专门适用于当前应用程序相关的功能代码，而不再将适用所应用程序的通用代码放置其中。

dclsFrm是框架（Framework）中为数不多的几个监管类之一。我们会在后续的系列中介绍其他的几个监管类。

我们现在有了一个我们可以称之为迷你型的框架。我们有了一个窗体类，我们可以使用它来将更多的窗体功能挂上去。我们有了一个控件类dctlTextBox，它给我们演示了控件自动扫描和加载的概念，我们也可以添加更多的功能到这个类上，而不仅仅只是背景色的自动变化。更加重要的是，我们需要让框架（framework）的基础被创建出来，而这便是另一个叫做clsFramework的监管类要做的事情了。

译者注：其实frmPeople5中的代码还有进一步简化的可能性！Form_Close事件代码完全可以移到类dclsFrm中去处理。我们只需要在类dclsFrm的头部定义窗体变量mfrm时添加一个关键字 WithEvents即可。由于本系列主要讲监管类，具体不再展开讲了。可以参见示例5.25.2监管类dclsFrm示例

类是什么？

类是 VB / VBA 中的一个模块，它是一个特殊的模块。类用于 Hold 住代码和数据，这些代码和数据用于描述某个对象，实现该对象的行为和属性。让类区别于 VB / VBA 中其他模块的是，类是完整加载于内存中的，而且可以加载不止一次。实际上，每实例化一个对象的时候，类就会被加载一次。

在设计类的时候，使用数据范式模型是很有用的。表是对象的模型，在设计表的时候，最好不要将 2 个及以上的对象建模到 1 张表里面。同样的道理，类也应该只对单一对象建模。我们应该避免让类 Hold 住或实现 2 个及以上的不同的对象。假设你有一个“银行”类，那么这个类应该使用诸如“账户”，“客户”，“支票”，“存款”等银行相关的类，这些类中，每一个都只需要存储它所建模的对象的数据，也只需要放置它所建模的对象行为的实现代码。如果一个类既描述银行，同时又描述账户，客户等，那注定乱成一团。

所以，如果一个类描述了一张支票，那么它肯定有支票号码属性，签发日期属性，金额属性，签名属性等。直到被加载到内存，这个类才可以描述任何能与它相匹配的支票。在这个类加载到内存，这些属性都赋值数据之前，它是不能描述任何东西的。这张支票号码是 1234，签发日期是 2000 年 1 月 1 日，金额 $123.45，是由史密斯先生签发。这个类的实例才描述了一张特定的支票。如果有一堆支票，你需要用类来管理它们，那么你需要为每一张支票都加载一个类的实例。

类通常都会在内存中加载多次，用来描述某个对象的多个实例。然而这并不是必须。我们也可以设计只加载一次的类，在这种情况下，开发者主要看中了类的封装特性。将所有的代码和变量都集中放在一个地方，类被实例化成对象后，这个对象知道如何来做一些事情。举例来说，我的框架有一个框架类。这个类只加载一次。这个类知道如何从表中读取加载参数，配置自己的属性，它也知道如何加载其他的服务类，例如 MD5 加密类，它也知道如何计算应用程序加载的对象的个数。这样，在标准模块中定义一个变量，运行一个函数，这个函数将我的框架类的实例赋给这个变量，然后初始化这个类的实例，一环套一环的事件发生，让其他的类也加载到内存，我的应用程序被设置好，准备开始工作了。当这些做完后，我可以调用我的框架类的方法，为我提供服务：压缩 / 解压缩文件，加密 / 解密文件，以及更一般的充当框架管理的角色。

总的来说，类是一种特殊的模块，这个模块中存储的是代码和数据，这些代码和数据是用来描述某个对象的行为和属性，每个加载到内存中的实例都对应着一个对象，这些对象可以用来帮我们做一些事情。

为何要使用类？

我已经简单的描述了类，现在，让我们来使用它。首先，每一个窗体都有（或都可以有）一个内建类（Built in class），当加载这个窗体时，这个内建类的一个实例就被加载到内存。这个内建类中有一些事件，例如打开事件（Open），关闭事件（Close）和更新后事件（AfterUpdate）。它也能被用来为窗体本身设置属性。对任何类来讲，ME 这个关键字是用来指代这个类的当前实例。换句话讲，如果你想在代码中设置窗体的标题属性，可以使用代码 Me.Caption=”Some text” 。因为“窗体后面的代码” 是驻留在窗体的类中，任何在窗体中写过代码的 Access 开发者就已经使用过类了。

类是窗体的一部分，这个事实非常美好的一点在于，你可以导出这个窗体到另一个数据库，窗体模块（类）中的代码也被跟着一起导出了。不幸的是，这也导致了一些维护上的困难，如果你在窗体模块（类）中写了非常复杂的代码，在另一个窗体中也需要相同的代码的话。很多开发者只是简单的复制和粘贴这些代码到另一个窗体中就完事了。如果代码有 Bug 怎么办？你需要打开 2 个窗体，清除这个 Bug。如果你将这个窗体导出到了另外一个项目中怎么办？你需要打开 2 个项目，修改代码清除 Bug。

认识到这是一个问题后，一些开发者开发了库（Libraries），将这些代码保存到他们自己的库中。这种方式运行得非常好（这也是我的做法）。现在，如果一个文本框的 OnEnter 事件需要调用一个函数，这个函数在库中，两个窗体都调用这个相同的函数。如果这个函数有 Bug，在库中修复这个 Bug，任何使用这个函数的地方就都没问题了。这种方法比之前好多了。

然而我们仍然有事件本身的问题。为了让复选框的 OnEnter 事件调用一个方法，这个事件会执行一段代码。对 99% 的 Access 程序员来讲，这段代码都会放在复选框所在窗体的窗体模块（类）中。我并不是说这种方式有什么不对，但是当一个大的窗体上有 10 个 标签页，80 个控件在其上时，每个控件触发 3 或 4 个不同的事件，再加上半打窗体本身的事件，再加上 30 个一般的执行调用函数，再加上……你懂了吧？现在这个窗体就像噩梦一样，非常难以维护。在海量的事件代码中，翻上翻下的来查找修改一点东西。

事实上，其他 Office 程序 （Word，Excel，Access，Powerpoint）的主要问题之一就是控件没有自己的类，与窗体不一样。因此，窗体类被当做了控件类。还记得之前说过的吗？类应该只为一个对象建模。我们现在已经遇到了一个类既为窗体建模，又为各种不同的控件建模。嗯……

下述示例演示了，当用户在控件中移动时，如何改变活动文本框的背景颜色。打开 frmPeople1 窗体，按 Tab 键观察一下活动光标。（点击该连接：Access框架研究系列之4 控件类示例下载本章所有示例代码文件）

将这段代码放到一个窗体模块中，添加 2 个文本框，命名为 txtFName 和 txtLName 。打开这个窗体，当光标进入到这 2 个文本框中时（OnEnter 事件发生），文本框的背景颜色变成了淡蓝色。当光标退出这 2 个文本框时 （OnExit 事件发生），文本框的背景颜色还原成原来的颜色。感觉很酷吧？但是来看看我们遇到了什么吧。我们需要在窗体顶部为每一个我们想使用该效果的控件定义一个变量，来保存旧的背景色。如果只有一两个控件需要使用该效果，那还算好。但是如果有 20 个或 40 个控件需要使用该效果，那该怎么办？更进一步来讲，我们不仅需要变量来存储这些东西，我们还需要为每一个控件设置 OnEnter 和 OnExit 这 2 个事件，乘以 20 或 40  个控件，那就是40 或 80 个事件代码，够痛苦吧？

幸运的是，我们可以创建类来为控件建模，比如一个文本框。我将选用这种简单的控件作为示例，以方便你理解它的工作原理，之后我会为其添加故障排查相关的代码。

以下是类 dclsCtlTextBox 中的代码。它代表着文本框的类，很简单也相当有用。（点击该连接：Access框架研究系列之4 控件类示例下载本章所有示例代码文件）

注意到没有？我们有一个保存原背景色的变量；有一个常量用来保存我们选择的颜色，当文本框获得焦点之后，文本框的背景色会被设置成它；还有一个保存指向某个具体的文本框的指针的变量，而且被定义成能响应事件（Withevents）！这告诉程序这个类将会响应这个控件的事件。

接下来，我们有一个 Init 子程序，传入一个指向某个具体文本框的指针，我们将这个指针保存在类的头部定义的私有变量中。同时我们也将这个变量的 OnEnter 和 OnExit 属性设置成字符串 [Event Procedure]。

解释：将窗体或者控件的任何一个事件的事件属性设置成字符串 “[Event Procedure]”，会导致该窗体或控件在发生该事件时，为这个事件做广播，通知所有指向该窗体或控件的 WithEvents 变量执行该事件代码。因为这个原因，在类的 Init() 方法中，我们总是会将我们想要处理的事件的事件属性设置成 [Event Procedure]，这样，当对象发生这个事件时，类中的事件代码就能够被执行。

Term 方法用来释放或清除指向文本框控件的指针。最后文本框的OnEnter和OnExit事件的事件代码处理文本框的背景颜色变化和还原。

设计好了 dclsTextBox 类之后，我们就可以开始为每个我们想控制的文本框做类的初始化了。我将使用我的示例数据库中的代码来处理4个文本框。这些代码保存在窗体 frmPeople2中。（点击该连接：Access框架研究系列之4 控件类示例下载本章所有示例代码文件）

我们定义了类的 4 个变量，每个用一个不同的名字。

窗体的 Open 事件中，为这些类变量做初始化。

窗体的Close 事件帮我们做清扫工作。

就是这样！注意到没有？在窗体中，你找不到任何文本框控件的事件处理程序！原因当然就在于文本框类 dclsCtlTextBox 可以响应这些事件，我们没必要在窗体中再去响应了。（译者注：当然你完全可以在窗体中为该事件写事件代码，事件发生时，dclsCtlTextBox 中的事件代码会首先获得执行，然后程序会去执行窗体中的事件代码，也就是说，控件或窗体的事件完全可以在多个地方都获得响应和执行。）

我听到你已经开始抱怨了：“确实很酷，但是做初始化和善后清除工作的代码还是有不少啊！”你说的没错，使用这些繁琐的代码只是方便你理解，一旦你理解类的使用方法，我可以开始介绍一些技巧，简化我们的代码，如 frmPeople3 所示。（点击该连接：Access框架研究系列之4 控件类示例下载本章所有示例代码文件）

窗体 frmPeople3 中使用了类工厂（ClassFactory）函数和类清除（ClsDestroy）函数。

如果使用集合（Collection）去保存我们的控件类变量，我们就不再需要为每个控件都去定义一个类变量了，代码就更加的简洁了！如 frmPeople4 所示。（点击该连接：Access框架研究系列之4 控件类示例下载本章所有示例代码文件）

是不是更加的简洁了？我们可以创建一个窗体类来帮助我们做这些事情！！这正是后面章节要做的事情。

译注：如果说前3篇讲得都是很抽象概念的话，那么从本篇开始往后，你将会非常具体的了解 Access 开发框架的每一个细小的部分，从最基础的部分开始，到一个完整的框架构成。

（点击该连接：Access框架研究系列之4 控件类示例下载本章所有示例代码文件）

Access 的垃圾回收（garbage collection）跟它的健壮性相比差得太多。当我们开始使用更高级的结构，比如类（class）和集合（collection）的时候，我们可能会遇到对象没有从内存中释放的问题。如果你保存了一个指向任何对象，例如窗体，控件或自定义类的指针，并且你永远不释放这个指针，然后你关闭 Access，表面上看，你好像关闭了，但实际上，内存并没有被释放出来还给操作系统。这会导致内存泄露，以及一些古怪的问题，甚至会阻止 Access 的关闭。

假定你使用一个类，这个类可以初始化其他的类。类A实例化后赋给变量 clsA。clsA 实例化其他 10 个类，将这 10 个类的对象变量保存在集合（collection）中。当 clsA 被置为 nothing 后，一般会认为 Access 会自动的清除掉这个类中的所有变量，包含集合中的对象变量，指向记录集的变量，指向窗体和控件的变量等。不幸的是，实际情况并不总是这样。当它不是这样时，你要确保它能被清除。（翻译这段的时候，我特意在 Access 2010上做了一点测试，实际情况似乎总是能正常被清除。有兴趣的可以下载这个文件3.1 通过类创建一个窗体的10个实例，打开该文件后，可以运行宏“CreateObjA”, 实例化 clsA，clsA 在初始化的时候会创建10个Form1，将其保存在它的私有集合变量mcol中。你可以看到10个Form1的拷贝被创建并打开了。最后运行宏“ReleaseObjA”，简单的将 ObjA 置为Nothing。你会发现ObjA的10个Form1对象全部被释放，没有发生内存泄露。）

举例来讲，在我的框架中，我一直都使用类来为窗体和控件定制一些通用的特性。每个窗体的头部都定义了一个窗体类 dclsFrm 的公有变量，然后在该窗体的 OnOpen 事件中被创建和初始化，dclsFrm 初始化时，传递给它一个指向当前窗体内建类（built in class）的对象变量（Me），dclsFrm 将这个指向当前窗体内建类的指针保存在 dclsFrm 类的私有变量中，这个私有变量是在类 dclsFrm 的头部定义的。

这样做的的一个好处就是，当在函数中打开某个窗体的时候，它可以让这个窗体保持打开状态，直到这个函数退出才会被关闭。它也允许 dclsFrm 根据需要直接引用控件和窗体的属性。

注意到没有？这里有问题！问题就出在这是一个环形引用。窗体有一个指向类的对象变量，类也有一个指向窗体的变量。必须采取一点措施将类和窗体中的对象变量重置，以便让类和窗体能正确的关闭和释放内存。对象编程的一条公理就是：一个对象会一直驻留在内存中，直到最后一个指向它的对象变量被设置成 Nothing。（这里我也做了一个示例文件：3.2 环形引用无法卸载的示例下载打开该文件后，运行宏“CreateFrom1”后，代码会实例化一个Form1，然后在Form1的打开时，将Form1的头部定义的类变量实例化，将指向当前Form1的指针“Me”传递给 dclsFrm 的init 方法，该方法将该指针保存在类 dclsFrm 的私有变量mfrm中。这样就形成了一个环形引用。然后运行宏“ReleaseForm1”，你会发现Form1并没有关闭。如果将函数“ReleaseForm1”中的第一句代码取消注释，你重新运行整个环节后，你会发现Form1可以正常关闭了。）

此外，dclsFrm 有一个窗体扫描函数，可以遍历窗体的控件集合，为它扫描到的每一个控件实例化一个类。当它扫描完时，如果某个窗体上有10个控件，那么我就加载了11个类 – dclsFrm 和 10 个控件类。我将指向这些控件的指针保存在 colChildren 集合中，并以控件名作为索引关键字。这样，我就能用控件名通过遍历这个集合找到任何我想控制的控件。

现在，当窗体需要关闭时，我需要清空这个加载的类，关闭里面的所有内容并释放其占用的内存。我通过一个叫做 Term() 的方法函数来做到这一点。这个函数遍历 Children 集合，调用每个子类的 Term 方法，然后将指向这个子类的指针从 Children 集合中移除。

如你所见，如果每个类都有一个类似的结构，任何类卸载前，先调用它的 Term 方法，这个Term 方法遍历并卸载它的 Children 集合中的每一个对象。这样，一个类可能有10个子类，每个子类又可能有10个子子类，每个子子类……不管你继续往下走多深……既然调用父类的 Term 方法会首先调用子类的 Term , 调用子类的 Term 会调用子子类的 Term 方法，一直到最底层的类被卸载，然后这个链接会像涟漪一样返回到最初的父类。调用父类的 Term 方法最终将会有效的卸载掉其所包含的所有子类。

因为这个原因，我们势必要严格定义类的结构，让它有效提供加载和卸载的功能。它必须是永远的，自动的发生。

是的。说的没错。

事情不是这样的。就像上面提到的环形引用，或者一个指向控件的对象变量不能被卸载，导致 Access 不能将其父窗体关闭，所以这个类永远也卸载不掉，卸载链条的涟漪永远不会发生。

混乱发生了。我们需要帮助我们解决故障的工具。在这一点上，我要感谢Shamil Salakhedinov 的工具和想法。在我刚开始学习使用类的时候，我从他那里受益颇丰。

当我开始使用类的时候，我遇到的首要问题之一就是如何跟踪记载类的加载和卸载。加载一个类，当你用完之后，而不卸载它，会导致内存泄露，类所占用的内存不会还给操作系统。有时 Access 会在关闭时将内存释放出来，偶尔它会导致 Access 无法正确的关闭，这不仅会导致内存泄露，也会导致一些其他的问题。这些鬼魂一样的 Access 实例在 Windows 98 下是看不见的，据我所知，Access 2000 之前的版本中，这些实例是无法被关闭的。Access 2000 以及之后的版本，你可以使用任务管理器来关闭它。这两种方法都是丑陋的。因此，我们跟踪记录类的加载和卸载是非常关键的。

在我当前的框架中，我使用一个长整形变量，每个类在加载时，将这个长整形变量递增1。这是我的第一个工具，从 Shamil 那里拿过来的示例代码。

这段代码很有用，至少它告诉你加载的对象的总数。我决定我真的想知道加载对象的名字。为了做到这一点，我添加了一个集合，在其中，我添加了类的名字，当类卸载的时候，将类的名字在集合中移除掉。

然后我可以用一个函数将集合中的名字全部读书来：

这段代码工作非常好，我在系统中用了它很长一段时间。

对于新的框架，我决定将一个实际指向这个对象的指针也保存下来，而不仅仅只是保存对象的名字。这个类调用一个函数，在对象加载的时候，该函数将一个指向该对象的指针保存在集合中，另一个函数在该对象卸载的时候将它的指针移除掉。这样做了之后，我就有了一个单独的地方，在这个地方我可以查看和控制任何对象。我们要处理的问题之一是“指向这个类的指针存储在哪里”？换句话讲，类可能在窗体代码中被加载，那么指针就存储在窗体的头部变量中；或者类在某函数的一段代码中被加载，那么指针就存储在这个函数的当前变量中；亦或类在另一个类中被加载，那么指针就这个类的集合变量中。如果你想查看这个类，执行一个方法，检查一个属性等，你如何得到一个指向该类的指针呢？通过将指向所有加载类的指针存储在一个集合中，我们可以：

• 通过集合的Count属性，可以获得所有加载的类的总数
• 通过遍历集合，可以获取其中的对象名字列表
• 通过指向类的指针，可以根据需要来控制其对象

因为这些，我已经决定使用这种方法。

免责声明：非常重要的是，你要意识到，类不会真的从内存中卸载，除非最后一个指向类的指针被设置为 nothing。这样，如果你实例化一个类，将指向这个类的指针存储在集合中，同时也在窗体头部（举例来说）的变量存储这个指针。这个类是不会卸载的，除非你在集合和窗体中都删除掉了指向这个类的指针。如果你的代码在别的地方也保存了指向这个类的指针，这个类也是不会卸载的，除非这3个指针都被设置为nothing。我的类的 init() 和 term() 方法将指针保存在对象跟踪记录类的集合中，同时指针也被保存在当前类的的父类的 child 集合中（详见后续系列），当类卸载的时候，它会将这2个地方的指针清除掉。然而，如果你的代码在另外的地方保存了指向这个类对象的某个变量，我也不知道它，无法将其清除，那么这个类将一直无法卸载，直到你将你的指针设置成nothing。

一旦到了我们要使用这些功能的时候，我将创建一个类 clsInstanceStack 为框架提供对象追踪记录的服务。

（本篇讨论的是建立一个框架必须要解决的对象释放的问题，看不懂也没有关系。从下一篇开始往后，将从最基础的类的介绍开始，详细讨论创建一整套框架的每一个细节问题。有兴趣了解的请留言。另外网站也开通了QQ登陆功能。免去了注册的烦恼^_^）

当你使用任何编程语言编写一个应用程序的时候，在你编写的应用程序中，总会存在某些代码片段，它们除了能作用于当前编写的应用程序外，还能用于其他的应用程序上。

软件行业从诞生的第一天开始，主要关注的问题就是“代码重用”。所以程序员一直被教导，去设计“可重用的代码”，例如：

• 用函数（Functions）去替换程序中重复出现的代码块
• 用库（Libraries）将常用的函数打包起来，供程序员调用
• 面向对象编程（OOP）将代码和数据捆绑在对象（Objects）中，供程序员引用
• 对象库（Libraries of Object）
• 框架（Frameworks，亦或平台）

很多软件开发工程师从没到达过框架的层次，所以他们不懂框架是什么，也不知道它和库有什么不同。

库仅仅只是存放代码，函数，对象，可能还有全局变量（但很少）的容器。而框架其本身就是一个应用程序，它是一个结构，可以用来为开发者创建程序的基础部分，这样，开发者就不必一遍又一遍的，为他的每一个程序重复创建。

想象一下你是摩天写字楼的建筑商。每一栋建筑都需要一定的服务。你需要停车场，电力，给水排，电梯，空调，供暖，你还可以继续列举。再假想一下，你有一个停车场“模块”，你修改一下“停车数量”参数，然后“扑通”一声把它丢在地上，这栋写字楼的停车场就建好了。继续想象一下，你用相同的方式将剩下的电力，给水排等服务都建好了。全套繁重的写字楼设计和建筑工作就这样完成了。更进一步来讲，想象你有全套的摩天写字楼结构，你只要简单的修改一下“停车数量”，高度，宽度，建筑的层数，电力系统的安培数，电梯的个数，电梯的高度，等等。你瞬间就有了一栋高层建筑，可以开始准备招商了。

这就是框架（Framework），但要以编程的角度。

有成吨的“服务”可供你的应用程序使用的话，那是再好不过了。这些服务就是那些“模块”，当你需要它的时候就创建它，当你用完它之后就拆掉它。这当然是可行的，这也是许多程序员做事情的方式，然而，这种方式需要手动的地方非常多。

我们假定某个开发者需要一个服务，比如将所有的系统错误记录下来。这种功能最典型的实现方式是用类，这意味着，你需要用这个类创建（实例化）一个对象，做完工作后，再将它卸载掉。或者，你可以让框架帮忙负责创建和卸载。你只需要调用框架的一个叫 “LogInit” 的方法，传递一个路径参数，指示你想把这个错误保存在什么地方。然后任何时候，系统发生错误，调用 “Log” 方法，传递系统的错误信息参数，系统错误就被记录下来。框架负责初始化这个 Log 类，存储路径信息，如果路径不存在则创建这个路径，当框架关闭时，卸载这个 Log 类。

再举一个稍微复杂一点的实际应用中的例子：为窗体装载控件类。我使用一个绑定窗体，我有这个窗体的类，同时也有组合框的类，文本框的类等等。组合框的类“懂得”如何处理“不在列表中”事件。如果我预先指定一个列表窗体，组合框的“不在列表中”事件会告诉用户他输入的数据不在列表中，是否想将其添加进去。如果用户说是的，类就以模式的方式打开指定的窗体。通过这个窗体，用户可以添加新的数据项进来。当用户关闭列表窗体后，组合框的类重新查询数据源，在列表窗体中新添加的数据项就可供选择了。

窗体类“懂得”如何去扫描窗体寻找放置其上的组合框控件。如果找到，框架会为每一个组合框都创建一个组合框类的实例。开发者只需要在窗体里面设置好代码，创建窗体类。窗体类会自动的去扫描和加载控件。当初始化完成，（在窗体类的 Init() 这一行之后），开发者可以为组合框指定相关的列表窗体。

所有这些功能都是框架要做的事情。对象类知道如何做事情。框架会记录对象的加载和卸载，在可能的时候自动清除掉对象。各种功能各司其职，因为框架会让这一切确保发生。

译者的话：

这篇文章主要介绍什么是框架以及与库的区别。用摩天写字楼的建设做类比也足够形象。

文中举的第二个例子，相当于我们谈论的控件子类化。将组合框的“不在列表中”事件的处理代码，从其所在窗体转移到组合框的子类中。组合框的子类由窗体的子类负责实例化。

关于该例子，后文中将会放出源码示例供大家参考。

通过子类化，你可以为 Access 的一些对象添加不存在的功能。子类化也许可以作为 VBA 的一个单独的话题拿出来讨论。

P.S.

我估计 Colby 的文章写于 2007 版 Access 出来之前，因为这之后，组合框的属性中就多了一条“列表编辑窗体”属性，开发者可以在此处直接指定一个窗体去负责处理不在列表中的事件发生时使用哪个窗体去编辑列表。

 

在夜深人静的时候，我常常想，如果若干年后我不再从事 Access 开发，我所拥有的开发经验中，哪些是最值得与大家分享的？一个函数？一个算法？一个用户界面设计？一个经典项目的全部代码？都不是！

我想，没有什么比这篇文章更能代表我最想分享的内容了。它代表着编程的核心思想在Access 中的最佳实践。

老实讲，这个思想不是我首创的。2008 年的某一天，忘记了是何缘故，访问到了这个网站：www.colbyconsulting.com 。里面有一个系列文章，标题就是《Access Class & Framework》。我当时还不是一个专职的 Access 开发人员，也只是偶尔用 Access 开发一些专供自己偷懒用的工具。看到这篇文章以后，我如获至宝。迅速就将所有的文档和示例文件全部下载保存下来了（事后证明这是多么明智的举动）。一两年以后，这个 Access 博客网站就变成了一个卖山地自行车的网站，Colby 放弃做 Access 咨询了？到目前为止，访问这个网站显示“因信息安全问题被屏蔽”。我后来一直在google Colby的信息，始终无法找到他。

Colby 的文章没有给你一个现成的开发框架（Framework），相反，他循循善诱，一步一步的给你娓娓道来，让你了解这个开发框架的核心思想是怎样的，如何在 Access 中去实现。我根据文章的指导，结合他给出的示例代码，创建了自己的 Access 开发框架。目前在工作中，也在使用我自己创建的开发框架。但是由于精力的缘故，一直没有对自己的开发框架进行更进一步的功能提升。例如可以将 “Access 用户界面 v1.0” 集成到开发框架中，更多的功能也能够添加到开发框架之中，好多事情都没来得及做。

现在，我准备一边编译（编辑+翻译）他的文章，一边向国内的 Access 爱好者们分享这一编程思想，同时也促成自己重温这些思想，继续提升自己的开发框架的功能。

以上。

P.S.

我将 Colby 说的 Framework 一词翻译成了“开发框架”，其实我本来是想将其翻译成“开发平台”的。后来担心与国内的 2 大 Access 论坛 / 网站上的“开发平台” 相冲突，就改成“开发框架”了。我私下认为如果你将 Framework 理解成“开发平台”也是合适的。

国内有 2 大 Access 论坛 / 网站，上面都有“Access 开发平台” 供免费 / 收费下载，都做得非常优秀。我有下载免费的版本，因为看不到核心的代码，所以不敢肯定这 2 个“开发平台” 都遵循了 Colby 文章中的思想。在仔细研究了其核心平台文件的类列表信息后，我只敢确认其中之一应该不是遵循 Colby 思想的产物，而是使用“库”（Library）来达到代码重用的目的，与“开发框架”（Framework）代码重用的方式，却差了一个级别。