如何提高Visual FoxPro的性能
一组表单共享一个私有数据工作期时才使用表单集。当我们运行一个表单集时，即使只显示了表单集的第一个表单，Visual FoxPro
也会创建表单集中所有表单和所有表单中的所有控件，这样很费时间。如果表单不必共享一个私有数据工作期，这样做是不必要的。我们应该建立独立的表单并在需要它们时执行
DO FORM 命令。
当然，如果使用了表单集，在访问表单集中的表单时也会得到些好处。因为所有表单已被加载到内存中了，只是没有显示，所以显示表单会比较快。
3．向页框中动态加载页面控件
与表单集类似，当加载页框时，也加载了每个页面上的所有控件，从而降低了性能。我们可以创建页框中每个页面上控件的类来解决这个问题。使用这个技术，由于直到访问时才加载页框中第二及其他页面上的控件，所以可以加速表单的加载。
4．动态绑定控件与数据
对于一个包含很多与数据绑定的控件的表单，如果我们将绑定的时间延迟到需要的时候，也可以极大地提高表单的性能。
我们可以将表单使用的表和视图放在数据环境中，这样当加载表单时表和视图就打开了。然后，当一个控件（例如组合框）获得焦点时，我们可以将控件与数据值绑定。
5．使用 LockScreen属性
任何对表单上控件的更改，这个属性允许我们延迟屏幕刷新。例如，使控件可见或不可见，更改控件颜色，或者在绑定型控件中移动记录，都可以用这个属性将它们延迟到所有更改都结束时再刷新，这样系统的效率会更高。
6．在视图中使用 NoDataOnLoad 属性
视图的数据环境临时表对象的 NoDataOnLoad 属性与视图的 USE 命令的 NODATA
子句的作用相同。它打开视图，但是视图不取得任何数据。对于本地和远程视图都是如此。例如，我们有一个有关客户信息的表单，它使用一个包含客户信息的视图，该视图使用参数代替
customer_id 的具体值。我们可以输入一个有效的 customer_id，然后按下“搜索”按钮。
这样做的优点是表单的加载时间大大减少了，因为视图不给我们带来任何数据，但是与视图字段绑定的控件仍是绑定的，因为存在一个打开的工作区（只是其中没有数据）。
四、完善OLE 的性能
在访问 OLE 数据之前先运行 OLE 服务程序。如果与通用字段数据类型相应的服务器（例如 Microsof
Word）在客户机的计算机上已经运行了，则与通用字段绑定的控件通常会获得更好的性能。
1．自动化的性能
在某些情况下，即使已经运行了一个实例，OLE 服务器（例如 Microsoft
Excel）仍然经常启动另一个新的实例。要想改变这种情况（并提高性能），请使用 GetObject 函数而不要使用 CreateObject
函数。例如，下面的调用：x = GetObject (, "excel.Application")总是使用一个已存在的实例，但是，x =
CreateObject ("excel.Application")将创建一个新的实例。
如果我们调用了 GetObject() 函数，而服务器还没有运行，系统会返回一个错误。我们可以俘获这个错误并在错误处理程序中调用
CreateObject() 函数。
2．不使用 MEMLIMIT
Visual FoxPro 不能识别 MEMLIMIT。在 FoxPro 中，MEMLIMIT 是一个配置设置，指定 FoxPro
分配供自己使用的最大内存数。不要使用这个配置设置来限制 Visual FoxPro 使用的内存数量。如果必要，请使用 SYS (3050) 函数。
3．“作为图标”插入对象
当我们将一个 OLE 对象插入到字段中时，将它作为一个图标，而不要作为整个的对象。这样可以减少所需的存储空间，因为如果 Visual
FoxPro 同对象一起保存了一个“代表”映象，会占用大量的存储空间。另外，如使用图标，绘制该对象的性能也会提高，因为只需重画图标。
4．尽量使用人工链接和图象控件
使用人工链接对象更快，因为自动链接需要的通知时间较长，而且人工链接不需要启动 OLE
服务器来绘制对象。如果不需要经常更新一个对象，请使用人工链接。
如果在一个应用程序中使用单独的位图（如，公司徽标），则图象控件要比 OLE 绑定型控件快得多。
5．使用 SYS(3050)
这个 SYS 函数允许我们优化用于数据缓冲的前台和后台的内存大小。前台内存是指当 Visual FoxPro
是前台（活动）应用程序时可用的内存。后台内存是指当 Visual FoxPro 是后台应用程序时可用的内存。
我们可以实际操作这些值，观察 Visual FoxPro 为它的数据缓冲占用多少内存，以优化我们的应用程序。
参考文献：
①胡维华主编《Visual FoxPro程序设计教程》，浙江科学技术出版社，杭州，2000。
②陈华生主编《Visual FoxPro教程》，苏州大学出版社
本文链接地址：http://www.oyaya.net/fanwen/view/173535.html
也会创建表单集中所有表单和所有表单中的所有控件，这样很费时间。如果表单不必共享一个私有数据工作期，这样做是不必要的。我们应该建立独立的表单并在需要它们时执行
DO FORM 命令。
当然，如果使用了表单集，在访问表单集中的表单时也会得到些好处。因为所有表单已被加载到内存中了，只是没有显示，所以显示表单会比较快。
3．向页框中动态加载页面控件
与表单集类似，当加载页框时，也加载了每个页面上的所有控件，从而降低了性能。我们可以创建页框中每个页面上控件的类来解决这个问题。使用这个技术，由于直到访问时才加载页框中第二及其他页面上的控件，所以可以加速表单的加载。
4．动态绑定控件与数据
对于一个包含很多与数据绑定的控件的表单，如果我们将绑定的时间延迟到需要的时候，也可以极大地提高表单的性能。
我们可以将表单使用的表和视图放在数据环境中，这样当加载表单时表和视图就打开了。然后，当一个控件（例如组合框）获得焦点时，我们可以将控件与数据值绑定。
5．使用 LockScreen属性
任何对表单上控件的更改，这个属性允许我们延迟屏幕刷新。例如，使控件可见或不可见，更改控件颜色，或者在绑定型控件中移动记录，都可以用这个属性将它们延迟到所有更改都结束时再刷新，这样系统的效率会更高。
6．在视图中使用 NoDataOnLoad 属性
视图的数据环境临时表对象的 NoDataOnLoad 属性与视图的 USE 命令的 NODATA
子句的作用相同。它打开视图，但是视图不取得任何数据。对于本地和远程视图都是如此。例如，我们有一个有关客户信息的表单，它使用一个包含客户信息的视图，该视图使用参数代替
customer_id 的具体值。我们可以输入一个有效的 customer_id，然后按下“搜索”按钮。
这样做的优点是表单的加载时间大大减少了，因为视图不给我们带来任何数据，但是与视图字段绑定的控件仍是绑定的，因为存在一个打开的工作区（只是其中没有数据）。
四、完善OLE 的性能
在访问 OLE 数据之前先运行 OLE 服务程序。如果与通用字段数据类型相应的服务器（例如 Microsof
t Excel 或
Word）在客户机的计算机上已经运行了，则与通用字段绑定的控件通常会获得更好的性能。
1．自动化的性能
在某些情况下，即使已经运行了一个实例，OLE 服务器（例如 Microsoft
Excel）仍然经常启动另一个新的实例。要想改变这种情况（并提高性能），请使用 GetObject 函数而不要使用 CreateObject
函数。例如，下面的调用：x = GetObject (, "excel.Application")总是使用一个已存在的实例，但是，x =
CreateObject ("excel.Application")将创建一个新的实例。
如果我们调用了 GetObject() 函数，而服务器还没有运行，系统会返回一个错误。我们可以俘获这个错误并在错误处理程序中调用
CreateObject() 函数。
2．不使用 MEMLIMIT
Visual FoxPro 不能识别 MEMLIMIT。在 FoxPro 中，MEMLIMIT 是一个配置设置，指定 FoxPro
分配供自己使用的最大内存数。不要使用这个配置设置来限制 Visual FoxPro 使用的内存数量。如果必要，请使用 SYS (3050) 函数。
3．“作为图标”插入对象
当我们将一个 OLE 对象插入到字段中时，将它作为一个图标，而不要作为整个的对象。这样可以减少所需的存储空间，因为如果 Visual
FoxPro 同对象一起保存了一个“代表”映象，会占用大量的存储空间。另外，如使用图标，绘制该对象的性能也会提高，因为只需重画图标。
4．尽量使用人工链接和图象控件
使用人工链接对象更快，因为自动链接需要的通知时间较长，而且人工链接不需要启动 OLE
服务器来绘制对象。如果不需要经常更新一个对象，请使用人工链接。
如果在一个应用程序中使用单独的位图（如，公司徽标），则图象控件要比 OLE 绑定型控件快得多。
5．使用 SYS(3050)
这个 SYS 函数允许我们优化用于数据缓冲的前台和后台的内存大小。前台内存是指当 Visual FoxPro
是前台（活动）应用程序时可用的内存。后台内存是指当 Visual FoxPro 是后台应用程序时可用的内存。
我们可以实际操作这些值，观察 Visual FoxPro 为它的数据缓冲占用多少内存，以优化我们的应用程序。
参考文献：
①胡维华主编《Visual FoxPro程序设计教程》，浙江科学技术出版社，杭州，2000。
②陈华生主编《Visual FoxPro教程》，苏州大学出版社
《如何提高Visual FoxPro的性能(第3页)》
★读了本文的人也读了：