关于VFP连编后运行程序一闪而过的解决方法

关于VFP连编后运行程序一闪而过的解决方法
[日期：2006-06-05] 来源：作者：[字体：大中小] 笔者在两年多的新闻组生活中，曾数十次遇到过初学者对VFP的表单窗口属性所提出的问题，特别是"为何系统编译后运行时一闪而过"的问题，更是被频繁地提出。

现根据我的经验进行一下总结，以帮助初学者打掉这只拦路虎。

其实，这个问题之所以被频繁地提出，并非是由于初学者的理解能力有问题，而实在是VFP的设计混乱所致，以至于造成初学者理解上的混乱。

笔者曾在"济南万千"的"软件、编程、数据库"新闻组就此问题发过"窗口问题到此为止"的帖子，反响很大，现根据该帖进行整理，修正补足该帖中的一些不准确之处及遗漏。

本文所提"表单窗口属性"，是指那些不但影响表单本身的特征(例如长宽等)，而且对表单之外、项目之中的其它"元件"有影响的表单属性，它们包括如下三个：
[list=a] 属性意义可选值(黑体为默认值)
DeskTop 指定表单是否包含在VFP主窗口中 F./.T.
WindowType 指定表单对象运行时的动作 0-无模式/1-模式ShowWindow 指定在创建过程中表单窗口显示表单或工具栏0-在屏幕中/1-在顶层表单中/3-做为顶层表单
[/list]
下面针对上述表单属性以及VFP中"桌面(DeskTop)、屏幕(Screen)、表单(Form)"等概念谈一谈我的理解。

正因为VFP在此方面的设计混乱，也就决定了我不能系统地、有条理地分析这些问题，我做的只能是阐述一些事实。

1.表单是一个对象，外观表现上是一个窗口。

VFP的主窗口也可以说是一个"表单"对象，它有一个固定的名字叫"_Screen"，"_Screen"是一个特殊的表单对象；
2."ShowWindow"是规定表单在"显示方面的从属关系"的属性ShowWindow属性实际上仅有两种选择："作为顶层表单"与"在顶层表单中"。

为了表达方便，我们把具有前者属性值的表单称为"顶层表单"，后者称为"从属表单"。

二者在显示方面的不同地位是：顶层表单在Windows任务栏上有一席之地，从属表单却没有这种待遇；顶层表单最小化时，从属表单随之被隐藏，当顶层表单关闭后，从属表单随之关闭。

ShowWindow的第三种选择"在屏幕中（默认）"仅是"在顶层表单中"的一个特例，即为"在_Screen这个特定的顶层表单中"之意，选择此种属性值时，它一定是个"从属表单"了。

_Screen具有"顶层表单"的一切显示特征。

从属表单不能独立地被显示，必须与他的"主表单"一起显示，这个"主表单"要么是一个顶层表单要么是VFP的窗口(_Screen)。

不需要为一个"从属表单"指定一个"主表单"，"从属表单"打开时，自动选择当前的活动顶层表单作为其"主表单"，当然，如果选择了"在屏幕中"，则这个从属表单自然就以_Screen为其主表单了。

3."DeskTop"是规定表单在"显示方面的活动范围"的属性。

DeskTop仅对"从属表单"有意义，当从属表单的DeskTop=.f.时，它只能显示在它的"顶层表单"的尺寸之内，当这个顶层表单的尺寸比它的尺寸还小时，它将会被部分地遮住；当从属表单的DeskTop=.t.时，它的活动范围将不受它的顶层表单尺寸的限制，它可以显示
在电脑屏幕的任何地方甚至之外。

但不管它的位置离其顶层表单多远，一旦顶层表单最小化了，它会立即顺从地从电脑屏幕上消失。

4."ShowWindows"是规定表单被执行时的程序动作的属性
分两种情况：
(1)当表单的ShowWindow为"在屏幕中"和"在顶层表单中"时：a.当WindowType="模式"时，执行表单(DO FORM)后使得表单取得焦点，并且一直到它被关闭，在此期间，它的父窗口对象(可能是_Screen或一个顶层表单)的菜单系统及其所属的子表单都不能用。

就是说，在表单存在期间，它将一直霸占着焦点. b.当WindowType="无模式"时，表单存在期间不会霸占焦点。

有一个例外，当DeskTop=.t.时，执行它时会使系统菜单失效，而Des kTop=.f.时则不会。

(2)当表单的ShowWindow为"做为顶层表单"时：表单的WindowType属性不管是有模式还是无模式，都不会霸占焦点。

5.一般情况，用户的应用系统需要一个主表单（主窗口），您可以将_Screen作为这个主窗口，也可以将项目中的某个"顶层表单"做为"主窗口"，很难说那种更好。

但在此笔者建议使用VFP主窗口做为用户系统的主窗口，这样可能会省去一些麻烦，因为VFP的很多工具条窗口被设计成只能开在_Screen中，例如在打印预览工具条等。

程序编译成EXE后，前者启动时先显示VFP主窗口，后者直接显示程序员自己设计的顶层表单。

对于后者，为屏蔽VFP主窗口，一定要在Config.fpw写入Screen=off(Config.f pw应加入到项目中，这样连编后它将被包含进EXE中，这一来可减少提供安装文件的数量，二来也可避免被用户更改)。

另一方面，很多应用系统程序都喜欢有一个漂亮的或曰自以为漂亮的启动封面，然后再进入主控界面。

如果一方面不希望在显示自己的启动封面前有VF P主窗口抢镜头，另一方面又想让VFP主窗口做为程序的主控界面时，解决办法是：设计一个"顶层表单"做为启动封面，config.fpw中仍须写Screen=off，然后在启动封面展示够了自己的魅力之后，用一句_Screen.Show将_Screen打回原形。

6.ShowWoindow与DeskTop属性仅规定了Form在显示方面的特征，而在"对象"这一更加高级的层面上，"顶层表单"与"从属表单"彼此是平级的，而_Screen虽然在显示方面与"顶层表单"具有相同的地位，但在对象层面却是高一级的家伙，所有表单，不管你是"顶层表单"还是"从属表单"，都是它的子对象，这想起来就叫人糊涂，还是赶紧不想的好。

7."为什么我的程序编译后一闪而过？" 这个问题有两种可能性，第一种是程序执行完成并退出，第二种是程序正在执行，但界面被隐藏。

对于第二种情况，可直接按"Ctrl-Alt-D el"键观察到。

造成这两种情况的原因如下：我们先看下面的一段示例程序，假如下面的示例程序是项目的主程序，并且应用项目以VFP主窗口做为自己的主窗口。

*环境设置
Do Form myScreen &&启动封面表单_
Screen.Show &&显示VFP主窗口
Do myMenu.mpr &&安装菜单系统
RETURN
为达到在显示启动封面之前不显示VFP主窗口的目的，在Config.fpw中已写Screen
=off，当程序执行到Do Form myScreen这一句时，如果表单myScreen的ShowWindows 属性被设为"在屏幕中"，则不管是在开发环境还是在编译环境下，程序都将停下来，表单被显示在_Screen中，而_Screen被隐藏了，因此表单跟着也被隐藏了，所以在屏幕上什么也看不见。

这就是第二种情况的产生原因。

为了避免这种错误的出现，必须将myScreen表单的ShowWindow的属性设为"做为顶层表单"，这样就可使在_Screen被隐藏的情况下，my Screen仍然可以被显示出来。

但请注意，在此情况下，Do Form myScreen这句话执行后，程序并不能停下来，而是顺序地执行下去，一直到执行到RETURN后程序退出，这也就是著名的"一闪而过"现象了。

为此必须在程序中包含事件处理命令Read Events使程序停下来，如下：
*环境设置
Do Form myScreen &&启动封面表单
Read Events &&开始事件处理：使启动封面停下来
_ Screen.Show &&显示VFP主窗口
Do myMenu.mpr &&安装菜单系统
Read Events &&开始事件处理
RETURN
程序执行Do Form myScreen后，将启动封面显示在屏幕上，然后向下执行到Read Events开始事件处理，此时启动封面表单必须由用户关闭或由表单事件关闭，否则程序将一直停在Read Events这一句上。

不管myScreen表单由谁关闭，在关闭代码中必须包含一句Clear Events的停止事件处理命令，以便开始执行Read Events的下一句指令，顺序执行完成_Screen.Show及Do myMenu.mpr后，用户的主界面就建立完成，同理，此处还需要一个事件处理命令让程序再次停下来，开始菜单系统的命令处理，一般情况，菜单系统中将包含的"退出"项，其中有"Clear Events"清除事件处理代码，从而停止第二条"Read Even ts"事件处理命令，退出整个系统。

以上经验恐有谬误，敬请批评！
最后，VFP是个所谓"让我欢喜让我忧"的东东，有时百依百顺，有时莫名其妙。

未曾恋爱过的男性最适合习之，以便为今后的恋爱打下坚实的心理基础。

fbilo最新
----------------------------------------------
再讲一遍【一闪而过】和【Read events】
在梅子那边看到经典问题里面有这个题目，话说了一堆，却没说到点子上。

说实话，以前也从来没看到过说到点子上的文章。

大多数人也就是知道在主程序里面加了R ead events 后能够避免一闪而过的问题而已，到底是什么原理还是不清除。

其实很简单，主程序是个什么文件？它就是一个PRG。

普通的PRG文件执行情况是怎么样的？从头到尾，每一行代码执行下去，然后立即退出。

OK，现在，再想一想，我们想要做的，是怎么样一个程序？是一个会出现菜单、主窗口，等待我们选择某个功能去执行的程序。

也就是说，程序应该打开菜单、主窗口以后就中途停下来，等待我们操作的程序。

好，现在再想一下，怎么在PRG中间的某个地方让程序停下来进入那么一种状态？Wait w indow 可以做到，不过一按鼠标马上就又继续执行了，要让程序一直等着，即使进行了几个操作也不会退出，就只有用Read events了。

随便建一个PRG，不用把它设置成主程序，只要这个PRG中间有Read events，那么程序就会停下来等着，MSDN里面的许多示例就是这么干的。

现在，一闪而过的问题应该清楚了吧？你的菜单是打开了、主窗口是打开了，但是，因为没有进入这个等待状态，所以，程序马上继续执行到末尾然后退出，菜单、主窗口都马上又被关闭了。

这些，都是一瞬间就执行完的，结果，看起来就是一闪而过。

再看看Clear events，它的意思，就是从这种等待状态中退出。

许多人把Clear events 误会成一个退出程序的命令。

不对，Clear events 只是退出这种等待状态而已，如果你在它的后面再加上一个Read events，那么程序就又会进入一种等待状态而不会结束。

由于Cl ear events 并不是立即退出程序，因此，在Clear events 后面的代码还是会继续执行，比如我们用来关闭数据库、恢复系统环境设置等等的命令之类的，都可以放在Clear events 后面去执行。

这个解释，应该是【一闪而过】和【Read events】的最终解释了吧！：）。