第二章研究formservices示例程序.PDFVIP

第二章 研究formservices 示例程序 应老衲的要求，先研究这个formservices 示例程序。群主最新修订的qplugins.vcl.formsvc 单 元，我初步测试已经解决了主程序退出时的错误。 在开始分析代码之前，我们先回顾上一个示例中是如何显示插件中的窗体的。然后我们设想 一下如何自己设计一个通用的办法，让显示插件窗体更加方便。 在上一个示例程序中，我们需要把插件窗体显示到主程序的 Page 控件中。示例程序中是这 样做的： 1. 主程序与插件之间约定了一个IDockableControl 接口，其中有一个DockTo 方法。 2. 插件窗体定义了一个插件服务类 TDockableService ，并向插件框架注册了它的工厂类 TDockInstanceService 类。其中TDockableService 类实现了IDockableControl 接口，并定义 了一个FForm 私有变量来保存真正的插件窗体对象指针。 3. 主程序调用插件管理器的 ByPath 方法获得指定服务时，每调用一次，注册在框架里的 TDockInstanceService 服务对象都会建立一个新的TDockableService 类的对象实例，并转 型成IDockableControl 接口返回给宿主程序。 4. 窗主程序调用返回的接口的DockTo 方法，才真正建立一个插件窗体实例并显示出来。 我们发现，对于我们最常使用的插件窗体，每次都用以上方法来实现有些繁琐。而且除了 DockTo 把插件窗体显示在 PageControl 里，有时我们还需要让插件窗体能象普通窗体那样 Show、ShowModal 等。为了简化操作，伟大的swish 给我们提供一个 IQFormService 接口， 并提供了实现接口的类TQVCLFormService 。 下面，我们正式开始剖析示例程序，看这个接口是如何简化窗体插件的使用的。为便于理解 （主要是本人水平有限也看不懂核心代码），分析仅是粗线条大致流程性的。 我们先打开 源码中的FormService 目录下的formservices 工程组文件，如下所示： 在编译时，可能需要适当修改一下项目属性，因为群主发布时没有清理好，比如带包编译时， 依赖了某些不必要的包。我们只要去掉这些包，只保存vcl;rtl 包就行。如下图所示： 现在，我们先编译全部项目，然后运行主程序，看看效果： 按惯例，我们先查看宿主程序代码main.pas： 在单元引用部分，我们看到相比第一个示例程序，多引用了一个qplugins.formsvc 单元。 在FormCreate 事件中，与上一示例程序一样，都是框架加载器初始化，不多作说明。 这个单元里，我们也没有发现特别的接口定义，剩下的就只有一个按钮事件： 这里，我们看到了两个新的接口类型：IQServices、IQFormService。而且与示例一不同的是， APage 变量是标准的TTabSheet 控件类型，而不是示例一那样扩展了接口的TDockHostPage 类型。 然后，我们看到依然是通过ByPath 方法来获取服务接口 ，外面还包了一层 Supports 函数， 用于确保接口是我们预期的IQServices 类型并赋值给本地局部接口变量AParent 。 现在，AParent 是 IQServices 类型的变量了。注意 IQServices 的单词拼写形式是复数形式， 我们可以猜测它是一个类似接口数组的类型。从接下来的代码里，果然看到了熟悉的类似数 组操作方式。 for I := 0 to AParent.Count - 1 do begin … if Supports(AParent[I], IQFormService, AFormService) then … end; 循环遍历AParent 里的每一个服务接口对象，然后判断它是否支持IQFormService 接口，如 果支持，就建立一个新的TabSheet ，并调用服务接口对象(支持IQFormService 接口)的DockTo 方法来把插件窗口显示到TabSheet 中。 从上我们可以发现，IQFormService 接口作为框架提供的标准接口，代替了示例程序 1 中需 要我们自行定义的IDockableControl 接口（或其它功能的接口）