[摘要]1.怎样解决不可视类库操作中库容量的“恶性膨涨”程序员用面向对象编程都会涉及到类库，但当对象的继承关系达到两层以上时(这是很平常的现象)，只要一修改两层以上某个对象中的内容，就会惊奇地发现：尽管修改量极小(有时只是简单的删除)，但每一次的存盘操作都会使类库的容量(即用DIR看到的字节数)增加很多，...
1.怎样解决不可视类库操作中库容量的“恶性膨涨”
程序员用面向对象编程都会涉及到类库，但当对象的继承关系达到两层以上时(这是很平常的现象)，只要一修改两层以上某个对象中的内容，就会惊奇地发现：尽管修改量极小(有时只是简单的删除)，但每一次的存盘操作都会使类库的容量(即用DIR看到的字节数)增加很多，有时一次存盘操作可使其“容量”增加几十K！笔者有一个实际内容只有50K的类库，当调试完成后，发现该类库的“容量”是800多K。笔者曾在多台机器的多个版本上做过试验，问题依旧。在排除了病毒骚扰的因素后，可以肯定：这是Visual FoxPro自身固有的缺陷。
显然，这个问题给程序开发带来了不小的麻烦。怎样解决呢？笔者查过不少资料，做过多次试验，都不得要领。后来在一次偶然的操作中，却发现了一个简单而有效的“类库消肿”方法：
①.打开这个待处理的类库，进入其中的一个继承关系最复杂且最高层的对象(即最上层的父类)；
②.修改一下该对象中的任一个方法或属性(即增加一个字符，然后再删除该字符)；
③.保存并退出；
④.用Close all和Clear all彻底关闭类库。
此时再观察该类库的字节数，可以发现该类库的“容量”已恢复正常。
2.怎样为备注型字段建索引
Visual FoxPro3.0不支持长度变化的关键字，但笔者在实验后发现，如果所建索引的备注型字段的长度在建完索引后不再变化，那么建立备注型字段的索引还是可行的。但在建索引时必须注意：索引的表达式不能直接用备注型的字段名，还要略加变通，如用TRIM()函数把备注型字段括起来，就能顺利地为备注型字段建索引。
3.建立索引的字符型字段允许的最大宽度
资料中对此没做说明，经试验发现，此时索引允许的最大宽度为240个字符。
4.当某个对象(中的)方法的形参过多时，最好用属性数组来代替形参
这种手段可以使主要处理过程的逻辑性更加清楚可读。
为了保证实质上的封闭性，属性数组应该定义在主控方法所在的对象中；为了保证“视觉”上的封闭性(即增强程序代码的可性)，可以让属性数组与主控方法同名。
为了进一步加强主控方法的可读性，可为其专门增加一个附加方法只用于给做形参的属性数组赋值。
5.怎样在对象中定义属性数组
在定义属性时，直接用方括号给出行列值即可。如：A[5,9]，即定义了一个5行9列的属性数组。
6.怎样快速地建立Grid表格
在程序中使用过Grid表格的程序员都觉得这种表格的建立方法有些麻烦，特别是当表格的个数及表格项很多的时候，甚至会产生“恐惧感”。其实，只要能灵活地利用VFP的“表单生成器”，就能大大提高Grid表格的制作效率。
这里假设需要以TTT.DBF为处理对象建立一个Grid表格，因为字段很多，Grid表格的表格项数也相应的多，所以只能采用“变通”的方法，步骤如下：
①.建立一个只有两个字段的自由表aa.dbf，并使其中的一个字段能与TTT.DBF中的某个字段相关；
②.启动“表单生成器”，选择“向导方式”中的“一对多表单向导”；
③.在“一对多表单向导”的操作引导下，以aa.dbf为父表、TTT.DBF为子表的基本模式制作表单。在选择子表字段时，以未来Grid表格的需要来进行TTT.DBF字段的选取。
④.打开由第③步制作的表单，剪切表单上的Grid表格，然后再退出该表单；
⑤.打开您程序中需要使用Grid表格的表单，把在第④步上剪切的Grid表格复制到当前表单上。
至此，一个符合程序要求的Grid表格即制作完毕。无论Grid表格多么大，用本方法都能在两分钟内做出一个符合要求的Grid表格。而用“手工”制作一个仅50个字段的Grid表格一般需要半个小时(而且还可能出错)。显然，Grid表格越大，本方法的效率就越高。
7.用“避开”的手段使对象中的方法“浮”起来
所谓让对象的方法“浮”起来，是指让该方法运行时，能不受工作区、变量、已打开的数据表等的限制(即不受“现场”的限制)，而且不干扰其它方法运行的一种手段。过去在教科书上学到的原则是：先保存“现场”，待处理工作完成后，再恢复“现场”。对VFP等数据库系统来说，所谓“现场”多是指已经被占用的工作区、当前的磁盘目录、已打开的数据表以及可能使用或正在使用的数据变量或对象的属性等。
因此，我们完全可以用“避开”的方式来达到目的，以下是“避开”法的基本步骤：
①.在本方法的起点先声明变量私有化，记录好本方法启动前的工作区及磁盘目录；
②.寻找并返回一个还未被使用的工作区，在该工作打开一个需要的数据表；
③.做本方法的“本职工作”(包括调用其它方法)；
④.恢复本方法启动前的工作区及工磁盘目录；
⑤.退出本方法。
由以上步骤可以看出，“避开”方式的基本要点是“单进单出”，以数据表为例：同一方法打开的数据表必须在该方法退出时关闭。对于工作区、磁盘目录亦有同样思路。显然，这种手段占用的内存要多一些，在DOS时代是不合适的，对于WINDOWS就不是什么问题了。
8.必须“自造”的几个通用的对象方法
以下是几个用得最多，但在VFP中却没有现成可用的方法：
①.在盘上查找指定的数据库
LPARAMETERS file_dbc
Private fff
fff=trim(file_dbc)
if len(fff)< 0.8
&&如果没指定数据库,就说明后面要用的那些数据表都是自由表,所以不用打开数据库
return .t.
endif
IF .not.file('&fff')
wait windows '在这个目录下没找到您指定的数据库！'
fff=.F.
ELSE
OPEN DATABASE &fff EXCLUSIVE
fff=.T.
ENDIF
return fff
②.在指定的(子)目录中查找指定的文件
LPARAMETERS file,Text &&即：文件名，提示信息
Private All
****** Like f*
fff=trim(file)
fff1=.t.
IF .not.file('&fff')
IF Len(Trim(Text)) >0.5
&&若提示信息的内容为空则不做暂停显示
wait windows Text
ENDIF
fff1=.f.
ENDIF
return fff1
③.寻找并返回一个还未被使用的工作区
Private ALL
for I=1 to 10
aaa_m=alias(I)
if len(trim(aaa_m))< 0.5
return I
endif
endfor
return 0
④.建立一个指定的目录
LPARAMETERS dire &&待建的目录名
Private All Like f*
fff='set Library to '+trim(This.path_FTS)
+'\Foxtools.FLL Additive'
&fff
*set Library to Foxtools.FLL Additive
fff1=.f.
fff=trim(dire)
if mkdir(fff)=0
fff1=.t. &&建立成功
endif
set Library to
return fff1
9.快速查询备注字段
在对备往字段进行全文查找时，用ATC()函数比用AT-CLIEN()函数快数倍。
10.最近匹配检索
在使用索引查找命令之前先设置“SET NEAR ON”有时极有用处，该设置的含义为：当查找失败时，记录号定位于最接近匹配的位置上，而不是在数据库的末尾。比如对一个已打开日期字段索引的库，想浏览3月5日之后的记录，但事先只知道库中有许多不连续的日期记录，并不知道库中是否确有3月5日的记录。如果设置了“SET NEAR ON”，当库中不存在3月5日的记录时，就会定位在离3月5日最接近的3月6日或7日记录处，从而达到查询浏览目的。
11.检测某类文件
函数FIEL()只能检测某特定文件是否存在，不能检测某类文件是否存在，而系统函数SYS(2000,<文件名>)则可搜寻某类文件，只要参数“文件名”中含有通配符“＊?”即可。用这个方法还可以判断某子目录是否为空，只要“文件名”用“路径名”和“＊.＊”组成即可。
12.保护屏幕画面
当在数据库环境下调用DOS命令时，命令执行后输出的信息往往会破坏数据库环境已有的屏幕画面。当然用保存屏幕再恢复的方法可以解决，但不如使用Dos的输出重定向功能为好，这样输出的信息就不会向屏幕显示。比如命令“RUN COPY ABC.* A：”可以改为：
RUN COPY ABC.* A: >ttt.txt
此时可将本来要输出到屏幕的信息改道输入到临时文件ttt.Txt中去，保持屏幕不变。
13.调用大尺寸外部程序
在FoxPro环境下可以用RUN()命令直接调用外部Dos命令，但有时剩下的内存已不多，而外部程序又很大时就可能调用失败。在FoxPro中有个内存管理程序FoxSWAP可以解决这个问题。调用WP5的命令可以写为：
RUN／120 WPS
14.用覆差法更新数据
如果一个很大的数据库需要经常进行数据更新，是好不要用删除旧记录再增加新记录的方法，因为大数据库的物理删除PACK命令执行起来需要很长时间。此时最好用覆盖的方法,即把新记录的内容一一装人旧记录中。而这个过程最好用SCATTER命令和GATHER命令配合起来完成，前者的作用是把一条记录的所有字段内容存人一个数组变量中，后者的作用则是把数组变量的内容存入一条记录中。也就是说借用内存变量把新记录的内容传递到旧记录中，内存操作显然比磁盘操作要快得多。
……