到输出的日志 内容另一方面,有个有趣的技巧,也能一定程度的调试 xo,那就是把 xo 上面的出问题的控件,包括数据库控件和 Query 控件,及其连带的事件和函数整个拷贝到一个独立可执行文件的窗体上,同时拷贝客户端相关对象,让客户端 ClientDataSet 直连Provider。
甚至于我们还可以把整个 XO 及其父窗体加入到一个 exe 项目中,在窗体上用 ClientDataSet 直连 xo 上的 Provider。
不过这需要一定的技巧。
AO 的调试方法(注意:本部分内容仅适用于 V524 之前的版本)在 CBX 中,AO 的调试很方便,几乎和 Delphi 中调试一个普通的应用程序相同。
首先设定参数,在 Delphi 项目的运行参数设定里面,设定 Host 为 Debugger.exe 的全路径,设定 Parameters 为加上 ao 文件的全路径,如图:我们可以看到,调试的参数是:F:CBXSDK__DeployDemo.ao http://LocalHost/CBX/AppSvr.dll/Demo.ao它的意思是,AO 的文件为 F:CBXSDK__DeployDemo.ao,调试器的启动 URL 是http://LocalHost/CBX/AppSvr.dll/Demo.ao ,如果不设置启动 URL,则在首次运行后,需要输入浏览器地址并回车。
上述设定在 CBX Studio 中可以自动设置。
我们按下 F9 热键后,即可开启调试器对 AO 进行调试:但是,有时候我们会发现开发环境无法正常的设置程序断点。
产生这个情况的原因可能有两点:1、项目中没有加入调试信息。
我们应打开项目选项,确保开启调试信息: 在调试中,我们一 般情况将这些选项 全部选上,然后 Build 项目,即可开 始调试2、文件 BORdbk70.dll 没有正常注册,该文件位于 Delphi 的 Bin 目录下,或者超级绿色 Delphi7 的 CLXBase7IDEBin 目录。
我们可以运行 RegSvr32 全路径BORdbk70.dll,然后开发环境即可恢复调试功能。
渐入佳境——开始开发越来越复杂的 CBX 系统1、在开发过程中,我们需要适当压缩 CBX 内部数据库的大小:由于 ao 和 xo 模块 都是保存在 CBX 内建的 FB 数据库CBXAppSvrDataAPPSVRDATA.DBF之 中,所以在频繁的不断上传模块过程中,CBX 的程序库会逐渐膨胀,当系统交 付的时候,CBX 程序库的体积可能会相当庞大,针对这种情况,CBX 中提供 了一个压缩程序数据库的批处理 CBXAppSvrDataPackAppSvr.bat 。
我们可以 运行该批处理,即可达到压缩目地。
通常该批处理都能够正常的压缩程序库, 我们能够直接从 APPSVRDATA.DBF 的体积变化看出压缩的效果。
但是,也不 排除遇到批处理执行失败的情况,这种情况我们应该根据错误的提示内容来排 除故障。
我们至少应该保证在系统交付的前夕,CBX 程序库压缩一次。
2、注意 ao 的体积:在 CBX 开发的入门阶段,我们只要保证我们的 ao 能够在浏览 器中成功显示,就算胜利。
但是,对于正式开发高品质的 CBX 系统,我们不 仅要关注程序本身的功能,还需要关注其他多方面的参数,ao 的体积就是一项 重要的指标。
理想状态的 CBX 系统,其每个 ao 的体积应该控制在 300k 左右, 甚至更小,这样便能够充分发扬 BS 应用的轻便风味。
如果系统编译出来的 ao,大多都超过了 1M 体积,那么我们就应该引起警惕了,应该从下面的因素 来分析: a 是否在 ao 中放入了太大的图片、图标?这一点我们可以从项目源代码的 dfm 文件的体积很直观的看出来。
我们在项目代码目录中,对文件的体积 排序,体积最大的 dfm 文件应该不超过几十 k 的样子。
如果有若干巨大的 dfm 文件,那么说明项目中插入了很大的图片之类的资源。
在 CBX 开发 中,我们一般不主张把巨大的图片或其他资源放入窗体。
我们还应注意, 我们永远不要修改 ao 窗体上默认的 ImageListForBtns 控件里面的图标内 容,因为一旦修改,那么整个巨大的图标集合会在当前窗体上复制一份; 维持不修改,那么该图标集合仅仅存在于容器集成的根窗体中。
b 我们的 ao 是否没有引用 CBExt.dcp,但是却用了 CBExt.bpl 中包含的大量 的扩展控件?对于使用了大量扩展控件的 ao,我们还应该引用 CBExt.dcp,因为很多重要的第三方控件我们都融入了 CBExt.bpl,引用它 的 dcp 后,会把 ao 中用到的 CBExt.bpl 内所包含的控件体积都削减掉,从 而不至于在 ao 本身中又包入那些控件。
c 如果我们所用到的控件或单元在 CBRun.bpl 和 CBExt.bpl 所容纳的范围之 外,也会造成每个 ao 都被包入一堆相关单元的副本,造成所有 ao 的体积 都很大。
这种情况我们可以增设第三个共用 bpl,在该 bpl 中引用我们用到 的控件的单元,相关详细做法请参考《高级指南》中的“大型 CBX 项目 的模块化架构方式” 中的相关内容。
当然,如果我们对 CBX 已经相当的 熟悉,那么还可以尝试从新编译部署 CBExt.bpl,在该 bpl 中,将项目中不 用的控件单元去除,添加上我们所需的控件单元,从新编译部署 CBExt.bpl,并且从新打包 CBRun.rar,这种调整,需要我们必须从新编译 所有 ao。
在 CBX 开发中,我们使用控件应该非常谨慎,最好参考 CBXAppsUnits 目录下 uUsesHelper.pas 和 uUsesHelperExt.pas 两者 uses 的 单元范围来使用,它们分别对应着 CBRun.bpl 和 CBExt.bpl 的单元范围。
3、要为每个 ao 设定一个永恒不变的 key:在正式开发中,不要依赖 CBX Console 自动生成 ao 的 key。
一旦 ao 的 key 固定下来,我们就不要轻易的改变它。
每个 ao 的 key,相当于该 ao 的身份标示,我们可以在程序之中通过 key 来利用 TAppletRunner 类动态加载运行该 ao。
一旦 ao 的 key 有了变化,那么 ao 之间的 相互调用就会出现混乱,特别是对于主框架模式的 ao 结构,更是如此。
正式的 CBX 系统的开发中,我们应该星系的维护一个 ao 列表,例如维护在项目文档 中的一个 Excel 文件中,里面不仅包含了系统中所有模块的构成、模块名称、 功能说明,而且还要清晰的记录每个模块的 key 值。
我们每次整体升级 CBX 框 架的时候,也应首先把当前程序列表导出,安装好新的 CBX 后,将列表导 入,然后再部署文件和程序模块,这样保证了模块的 Key 都一成不变。
4、每个 ao 或 xo 的配置信息可以在 Console 中设置。
设置配置文件,是专业 CBX 系统开发必然涉及的内容。
因为我们不可能把硬盘路径、数据库连接串、系统 运行参数等信息固化到我们的程序代码中,我们的系统必然允许用户根据现场 情况而作相关的设置。
如同一些其他的大型系统一样,CBX 系统也会涉及配置 文件的读写。
但是特殊之处在于,CBX 系统的所有配置信息,一般都在服务器 上保存和维护,而不提倡像 CS 系统那样保存在客户端,尽管完全可以做到。
CBX 本身提供了一个特别便利配置文件机制:CBX 程序库为每个模块都提供 了一个配置文本存储字段,并且,在系统加载阶段,我们可以直接从 ao 或 xo 主窗体本身的 ConfigData 属性中读取到配置文件。
我们一般都是在 ao 的 InitModule 函数中,或者 xo 的 InitEntity 函数中,读取配置文件的变量值,形 如:ConfigData.ValuesMyVar。
在配置文件中,我们写入若干行形如 MyVarMyValue 的信息。
我们编辑配置文件,是通过 Console 来做的: 我们点击此按 钮,即可编辑 每个模块的配 置文件 编辑完毕后,我们不要忘记按保存按钮。
每个模块都可以通过这种方式获取配 置信息,无论是 ao,还是 xo。
但是如果我们在框架式 ao 中有大量的子 ao 需要 共享同一组配置数据,那么我们不应该重复性的为每一个 ao 设置相同的配置, 而是利用主 ao 的配置,将配置信息写入 bpl 的全局变量,让所有的子 ao 通过 bpl 的全局变量来读取相关参数,而不是通过
上一篇:
【精品】文件后缀名解释
下一篇:
管理硕士论文题目(教授推荐150篇)