4.3 LabVIEW圖形化編程語(yǔ)言的編程范式

當(dāng)前正在審批4.3LabVIEW圖形化編程語(yǔ)言的編程范式(LabVIEWgraphicalprogramminglanguage,programmingparadigm)版本7

創(chuàng)建于:2010-12-4下午7:01作者jwdz-最后修改:

2010-12-19上午12:35作者jwdz

上一節(jié)中曾簡(jiǎn)要介紹了編程范式和幾種常見(jiàn)的編程范式。在本節(jié)中，我們將要進(jìn)一步說(shuō)明LabVIEW圖形化編程語(yǔ)言的編程范式。

首先，我們要給出上節(jié)中所提到問(wèn)題的最終答案。其實(shí)答案很簡(jiǎn)單：LabVIEW是一種多范式的圖形化編程語(yǔ)言，它基本適合我們上面所談到的幾種編程范式。這也是上節(jié)中給出這幾種編程范式的真實(shí)目的。

下面我們就來(lái)一一的進(jìn)行簡(jiǎn)單分析。

4.3.1LabVIEW圖形化語(yǔ)言的過(guò)程化（命令式）編程

我們已經(jīng)知道：過(guò)程化編程要求程序員必須要知道程序要完成什么，并且告訴計(jì)算機(jī)如何來(lái)進(jìn)行所需的計(jì)算工作，包括每個(gè)細(xì)節(jié)操作。簡(jiǎn)言之，就是將計(jì)算機(jī)看作一個(gè)善始善終服從命令的裝置。

作為L(zhǎng)abVIEW的實(shí)踐者，此階段可能已經(jīng)完成了許多圖形化代碼的程序設(shè)計(jì)工作，因?yàn)槲覀冋J(rèn)為本書(shū)的讀者對(duì)LabVIEW已經(jīng)有了充分的了解。但是，面對(duì)那些已經(jīng)完成的程序設(shè)計(jì)，大家可能根本無(wú)法感覺(jué)到我們?cè)谠O(shè)計(jì)中采用了什么樣的編程范式。那么圖形化語(yǔ)言如何實(shí)現(xiàn)過(guò)程化編程的呢？

圖形化語(yǔ)言過(guò)程化編程的表示方法

回顧第3章的部分內(nèi)容，我們就不難發(fā)現(xiàn)：基于數(shù)據(jù)流編程思想的LabVIEW圖形化編程語(yǔ)言中，最基本、最廣泛使用的編程范式應(yīng)該就是過(guò)程化（命令式）編程范式。這點(diǎn)對(duì)于學(xué)習(xí)過(guò)和使用過(guò)這種編程語(yǔ)言的朋友們來(lái)講，我深信，應(yīng)該是非常好理解的。

在基于數(shù)據(jù)流的LabVIEW編程思想中，我們所強(qiáng)調(diào)的數(shù)據(jù)依賴性和充分利用公共線程必將導(dǎo)致其程序結(jié)構(gòu)都是基于過(guò)程化的。所以采用過(guò)程化編程范式是LabVIEW圖形化語(yǔ)言最基本、最顯著的特征，是我們必須自覺(jué)、不自覺(jué)采用的基本編程方式。特別是在儀器控制和數(shù)據(jù)采集過(guò)程中，由于圖形化語(yǔ)言的自身的點(diǎn)，這種過(guò)程化編程范式顯得更自然、更容易理解。

下面我們一起來(lái)看幾個(gè)簡(jiǎn)單的實(shí)例。

例-1無(wú)相移濾波器

這個(gè)實(shí)例來(lái)自于LabVIEW2010(Mac版)自帶的例程（ZeroPhaseFiltering.vi）。這個(gè)例子就是依賴數(shù)據(jù)關(guān)系的過(guò)程化編程。

圖-1無(wú)相移濾波器實(shí)例

從工程應(yīng)用的角度看，通常所設(shè)計(jì)的濾波器的濾波結(jié)果對(duì)輸入信號(hào)都會(huì)產(chǎn)生一定的附加相移，有時(shí)候這個(gè)附加的相移是我們不希望出現(xiàn)的，而本例提供了實(shí)現(xiàn)無(wú)相移的濾波器。這個(gè)應(yīng)用在工程上是很實(shí)用的，通過(guò)這個(gè)實(shí)例可以加深對(duì)這個(gè)內(nèi)置vi的理解。

還有沒(méi)有更好的辦法來(lái)解決這樣的問(wèn)題？當(dāng)然有，我認(rèn)為我所設(shè)計(jì)的“理想濾波器”（相對(duì)于周期信號(hào)而言）與它有異曲同工之處。其實(shí)，“理想濾波器”的性能應(yīng)該是更佳，因?yàn)樗矊?shí)現(xiàn)了無(wú)相移的基波提取，同時(shí)給出基波的實(shí)際幅值。當(dāng)然它還可以改進(jìn)用來(lái)提取諧波分量等等。

感興趣的讀者不妨打開(kāi)鏈接看看。

例-2利用公共線程的過(guò)程化編程

圖-2利用公共線程的過(guò)程化編程——34401DMM測(cè)量溫度（RTD）

在LabVIEW程序中利用公共線程實(shí)現(xiàn)過(guò)程化編程的實(shí)例很多，第3章中所描述的內(nèi)容都與此相關(guān)，這里就不一一列舉了。

其實(shí)，絕大多數(shù)的LabVIEW程序設(shè)計(jì)都是基于過(guò)程化編程實(shí)現(xiàn)的?；蛘哒f(shuō)過(guò)程化編程是LabVIEW中最主要、最基本的編程范式。

圖形化語(yǔ)言過(guò)程化編程的基本特點(diǎn)

圖形化語(yǔ)言過(guò)程化編程基本的特點(diǎn)：

圖形化語(yǔ)言最基本的編程范式

毋庸置疑，對(duì)于圖形化程序設(shè)計(jì)，只要你貫徹?cái)?shù)據(jù)流的編程思想一些程序自然都是基于過(guò)程化處理的。這樣的實(shí)例我們見(jiàn)到很多，并且也做過(guò)許多這樣的程序設(shè)計(jì)。其實(shí)，過(guò)程化編程并不局限于上面所介紹的數(shù)據(jù)依賴性、利用公共線程等等方面。比如：順序結(jié)構(gòu)、狀態(tài)機(jī)、生產(chǎn)者和消費(fèi)者循環(huán)等所展現(xiàn)的程序代碼也都屬于過(guò)程化編程。

這種過(guò)程化程序設(shè)計(jì)的自然性根本無(wú)須特別的強(qiáng)調(diào)，依據(jù)數(shù)據(jù)流的編程思想人們便會(huì)在程序設(shè)計(jì)中自覺(jué)、不自覺(jué)的采用這種程序設(shè)計(jì)方式（過(guò)程式編程）。

簡(jiǎn)略的回顧一下，LabVIEW從誕生到現(xiàn)在的所有版本，一直都以過(guò)程化編程為最基本的編程范式，因?yàn)檫@些已經(jīng)貫穿在LabVIEW的編程思想中。

在測(cè)試、測(cè)量任務(wù)中，過(guò)程化的處理方式也是最基本操作模式之一。

自上而下還是自下而上的編程

通常的程序設(shè)計(jì)有兩種基本路線，自上而下和自下而上?；谖谋镜倪^(guò)程化編程，更強(qiáng)調(diào)“自上而下”的設(shè)計(jì)方式。圖形化的過(guò)程化編程即可以采用“自上而下”的設(shè)計(jì)方法，也可以采用“自下而上”的設(shè)計(jì)方法，當(dāng)然還可以同時(shí)采用這兩種設(shè)計(jì)方法同時(shí)進(jìn)行設(shè)計(jì)。這些僅僅取決于問(wèn)題的表述和你的設(shè)計(jì)習(xí)慣。

在通用應(yīng)用程序設(shè)計(jì)時(shí)，我們常采用事件驅(qū)動(dòng)VIServer或狀態(tài)機(jī)來(lái)控制程序的運(yùn)行（依據(jù)GUI的操作），開(kāi)始時(shí)我們并不需要為每個(gè)狀態(tài)都填寫(xiě)代碼，只要狀態(tài)運(yùn)行機(jī)制正確就可以。確定狀態(tài)運(yùn)行正確后，我們開(kāi)始對(duì)不同狀態(tài)撰寫(xiě)程序代碼，并且這些代碼可以分配給多人分別撰寫(xiě)。

在測(cè)試應(yīng)用程序設(shè)計(jì)時(shí)，我們通常先設(shè)計(jì)、實(shí)現(xiàn)基本測(cè)試、分析功能，當(dāng)這部分工作正常后在開(kāi)始設(shè)計(jì)其它的部分，如報(bào)告生成等。

實(shí)際上，我們習(xí)慣于先對(duì)涉及到硬件部分（數(shù)據(jù)采集、儀器控制等）的程序進(jìn)行整體設(shè)計(jì)（包括仿真試驗(yàn)），最后綜合設(shè)計(jì)完成其它的部分。

模塊化設(shè)計(jì)

過(guò)程化編程的關(guān)鍵是將待解問(wèn)題分解為自己可以理解的模塊。在LabVIEW中模塊是以子vi的形式出現(xiàn)的，每個(gè)子vi處理一個(gè)或多個(gè)任務(wù)。而子vi更優(yōu)異的特性是在于可重用。充分利用子vi的設(shè)計(jì)，實(shí)現(xiàn)程序代碼的直觀可讀性和簡(jiǎn)潔性。

模塊化設(shè)計(jì)子vi是一個(gè)非常好的選擇，考慮到vi的可重復(fù)使用，采用通用式設(shè)計(jì)是一個(gè)有效的解決方案。比如：我們有許多NI的數(shù)據(jù)采集硬件產(chǎn)品，實(shí)際上在做數(shù)據(jù)采集時(shí)可能會(huì)根據(jù)測(cè)試任務(wù)選擇不同的硬件。事先，我們可以設(shè)計(jì)一個(gè)標(biāo)準(zhǔn)的vi，實(shí)現(xiàn)對(duì)不同硬件的通道配置。實(shí)現(xiàn)的方法很簡(jiǎn)單，一個(gè)枚舉常量、一個(gè)Case結(jié)構(gòu)外加不同硬件的配置代碼。參見(jiàn)下圖。

-1模塊化的硬件配置

這是一個(gè)有效的模塊化設(shè)計(jì)的解決方案。由于NIDAQ產(chǎn)品配置與總線（PCI、PXI、USB、cDAQ）無(wú)關(guān)，所以它適用于大多數(shù)硬件配置。

它的最大好處是增加新的硬件很方便、很容易，僅僅需要添加一個(gè)枚舉常數(shù)和Case結(jié)構(gòu)中新硬件的配置代碼。

當(dāng)然，盡管這種方式提高了vi的重用性，但是同時(shí)也會(huì)增加vi所使用的內(nèi)存空間或磁盤(pán)空間，包括也增加了vi導(dǎo)入時(shí)所需的執(zhí)行時(shí)間。但這些對(duì)現(xiàn)代計(jì)算機(jī)的性能來(lái)講幾乎沒(méi)有什么負(fù)面的影響。

如果你注意到：LabVIEW2010的新特性，對(duì)模塊化的設(shè)計(jì)方法使用內(nèi)存過(guò)多的說(shuō)法就應(yīng)該不存在任何顧慮。因?yàn)長(zhǎng)abVIEW2010對(duì)編譯器進(jìn)行了優(yōu)化設(shè)計(jì)，使得vi經(jīng)過(guò)編譯后的執(zhí)行代碼會(huì)更簡(jiǎn)單、更直接。這樣講，似乎很難理解，我們針對(duì)-1做簡(jiǎn)單的說(shuō)明。

在-1中，我們針對(duì)不同的硬件設(shè)計(jì)了不同的配置代碼，目的是用模塊化的設(shè)計(jì)方法提高vi的可重用性。實(shí)際上，在程序運(yùn)行中我們僅僅用到了一種硬件的配置代碼，也就是由枚舉常數(shù)所定義的那個(gè)Case結(jié)構(gòu)中的硬件，其它Case結(jié)構(gòu)中的硬件配置代碼根本沒(méi)有使用到。LabVIEW2010編譯器對(duì)此做了處理，在生成的可執(zhí)行代碼中去掉了其它Case結(jié)構(gòu)中根本沒(méi)有用到的硬件配置代碼，近而提高了程序的執(zhí)行效率。并且，編譯本身并不會(huì)破壞vi的源代碼。

請(qǐng)注意，LabVIEW2010的這個(gè)新特性是利用增加編譯的時(shí)間來(lái)?yè)Q得程序執(zhí)行時(shí)間的降低，從而提高了編譯后程序執(zhí)行代碼的執(zhí)行速度。

(未完待續(xù))

4.3.2LabVIEW圖形化語(yǔ)言的事件驅(qū)動(dòng)編程

需要提醒大家的是：本節(jié)所要討論的是圖形化語(yǔ)言事件驅(qū)動(dòng)的編程范式。但我們不得不先介紹一些有關(guān)事件編程的其它知識(shí)。

我們知道：LabVIEW6.1推出了基于事件驅(qū)動(dòng)的編程方法。但是，在LabVIEW較早期的版本中，如LabVIEW6，就已經(jīng)包含有基于事件通知的編程方法（應(yīng)該說(shuō)是一種基于軟件的同步機(jī)制）。為了更好的說(shuō)明事件驅(qū)動(dòng)的編程機(jī)制，這里先簡(jiǎn)單介紹一下這部分相關(guān)內(nèi)容。

事件通知是一種同步機(jī)制，它允許LabVIEW程序中并行處理部件之間在事件發(fā)生時(shí)進(jìn)行相互通知。由于它采用的是利用軟件觸發(fā)的方式發(fā)出事件通知，這樣就避免了使用輪詢技術(shù)所導(dǎo)致的系統(tǒng)開(kāi)銷過(guò)大的問(wèn)題。

在程序設(shè)計(jì)中，可以利用一個(gè)事件源（GenerateOccurrence）來(lái)通知多個(gè)等待事件的用戶（WaitonOccurrence），從而起到同步觸發(fā)的作用。

在函數(shù)選板上可以看到這些基于事件通知的內(nèi)置函數(shù)。參見(jiàn)下圖。

圖4.3.2-1基于事件通知的內(nèi)置函數(shù)

Occurrence一詞的意思是發(fā)生（事件），它與event是同義詞。

在許多教科書(shū)中我們可以看到Occurrence函數(shù)的一些介紹。但是，在實(shí)際的程序范例中，我們真的很少看到使用Occurrence函數(shù)的程序（至少我的感覺(jué)是這樣）?？墒窃贠penG的vi包中，我們確看到了它的實(shí)際應(yīng)用。這就是它的：OpenG_Wait（ms）.vi。

圖4.3.2-2OpenGWait(ms).vi

它是用LabVIEW_Wait（ms）函數(shù)創(chuàng)建的vi，但比LabVIEW_Wait（ms）函數(shù)功能更強(qiáng)大。下面就是它的程序框圖。

圖4.3.2-3OpenG_Wait(ms).vi程序框圖——Case=True

圖4.3.2-4OpenG_Wait(ms).vi程序框圖——Case=False

它不僅有錯(cuò)誤簇輸入、輸出；還可以設(shè)定出現(xiàn)錯(cuò)誤時(shí)是否停止定時(shí)；同時(shí)還有一個(gè)事件通知的信號(hào)輸入端。前面幾個(gè)特點(diǎn)我們這里不談了（在《LabVIEW——北方客?！返摹皏idesign”和“OpenG”專欄中已經(jīng)評(píng)述過(guò)），這里僅談?wù)勈录ㄖ@個(gè)特點(diǎn)。

眾所周知，如果在一個(gè)While循環(huán)中放置一個(gè)長(zhǎng)時(shí)間的定時(shí)器，比如60s，當(dāng)用戶試圖使用條件終端停止這個(gè)While時(shí)，有可能需要等待很長(zhǎng)時(shí)間（最長(zhǎng)120s，為什么？）。參見(jiàn)下面的程序框圖。

圖4.3.2-5LabVIEW_Wait(ms)函數(shù)

這絕對(duì)是一件非常令人非常沮喪的事情。因?yàn)槲覀冊(cè)谕Ｖ苟〞r(shí)后，真的不希望存在過(guò)長(zhǎng)的等待時(shí)間。

現(xiàn)在來(lái)回答為什么可能要等待上120s的時(shí)間。

因?yàn)閃hile循環(huán)首先要執(zhí)行60s的定時(shí)循環(huán)（初始條件端為“F”），即便是我們?cè)诙〞r(shí)開(kāi)始后馬上按下了停止按鍵，定時(shí)循環(huán)也要執(zhí)行完這個(gè)定時(shí)。在完成這個(gè)定時(shí)后，條件端檢測(cè)到停止按鍵按下后(條件端為“T”)，還要在進(jìn)行一個(gè)循環(huán)才能結(jié)束。所以，最壞的情況下有可能需要等待120s時(shí)間。

現(xiàn)在，使用OpenG_Wait(ms).vi就可以解決這個(gè)問(wèn)題，它利用了Occurrence事件通知來(lái)消除過(guò)長(zhǎng)的等待時(shí)間。具體的程序框圖請(qǐng)參見(jiàn)下圖。

圖4.3.2-6利用Occurrence事件通知來(lái)立即停止定時(shí)循環(huán)（Case結(jié)構(gòu)假為空）

圖4.3.2-6最外面的循環(huán)是60s的定時(shí)循環(huán)，內(nèi)部是采用Occurrence事件來(lái)停止定時(shí)的循環(huán)。這樣我們就可以在任何時(shí)候都可以立即停止主定時(shí)循環(huán)。

其實(shí)僅僅使用Occurrence事件通知機(jī)制同樣可以實(shí)現(xiàn)同樣的定時(shí)功能（不使用Wait（ms）函數(shù)或vi），并且也可以立即停止定時(shí)循環(huán)。在《LabVIEW圖形編程》一書(shū)中就給出了這樣的實(shí)例，我們可以一起來(lái)看看它的程序框圖。

圖4.3.2-7利用Occurrence事件通知來(lái)消除過(guò)長(zhǎng)的等待時(shí)間（Case結(jié)構(gòu)假為空）

它是利用超時(shí)值來(lái)做為定時(shí)值進(jìn)行定時(shí)處理，并利用Occurrence事件通知來(lái)消除過(guò)長(zhǎng)的等待時(shí)間。

這里請(qǐng)注意：基于事件通知的圖形化程序代碼的運(yùn)行機(jī)制還是基于數(shù)據(jù)流的運(yùn)行機(jī)制。其圖形化代碼清晰、直觀、易理解。

清楚了事件通知的運(yùn)行機(jī)制，現(xiàn)在我們?cè)摶氐奖竟?jié)的正題，LabVIEW事件驅(qū)動(dòng)編程。

圖形化語(yǔ)言事件驅(qū)動(dòng)編程的由來(lái)

我們前面曾經(jīng)談到過(guò)，計(jì)算機(jī)可視化操作系統(tǒng)（Mac、Windows、Linux）的陸續(xù)出現(xiàn)為L(zhǎng)abVIEW提供了廣闊的生存空間和持續(xù)發(fā)展的基本環(huán)境。

在可視化操作系統(tǒng)中，人機(jī)對(duì)話基本上都是通過(guò)鼠標(biāo)、鍵盤(pán)的事件響應(yīng)來(lái)實(shí)現(xiàn)的。人們通過(guò)鼠標(biāo)的拖拽、點(diǎn)擊實(shí)現(xiàn)對(duì)計(jì)算機(jī)最基本的操作，計(jì)算機(jī)則通過(guò)用戶事件處理機(jī)制來(lái)響應(yīng)和處理來(lái)自用戶的要求。對(duì)于這些事件通常被稱為：GUI事件。

盡管在LabVIEW賴以生存的基本環(huán)境中，可視化操作系統(tǒng)都是采用用戶事件處理機(jī)制來(lái)響應(yīng)和處理用戶的要求。但是不知道什么原因，在LabVIEW6.1出現(xiàn)之前的早期版本中，人機(jī)對(duì)話并沒(méi)有相應(yīng)的GUI事件處理機(jī)制。那時(shí)，對(duì)用戶的操作響應(yīng)采用的是輪詢的方式來(lái)檢測(cè)用戶的操作，處理則采用隊(duì)列的方式來(lái)處理用戶需求。

輪詢的方法有兩個(gè)缺點(diǎn)：一是，占用CPU的資源；二是，可能遺漏用戶的操作請(qǐng)求。

自從LabVIEW6.1推出了事件驅(qū)動(dòng)處理機(jī)制后，就完全去掉了輪詢的這兩個(gè)缺點(diǎn)。使得GUI事件驅(qū)動(dòng)占據(jù)了用戶界面事件響應(yīng)處理的主導(dǎo)地位。這些事件包括鼠標(biāo)事件、鍵盤(pán)事件、窗體事件、對(duì)象事件等等。

事件驅(qū)動(dòng)機(jī)制的建立，使得LabVIEW在處理復(fù)雜事情方面能力大大的增強(qiáng)，可以更方便的實(shí)現(xiàn)用戶的多種需求（不僅僅是GUI事件，還可以處理用戶自定義的事件）。這樣LabVIEW也就具備了通用編程語(yǔ)言最基本的特性。

圖形化語(yǔ)言事件驅(qū)動(dòng)編程的表示方法

圖形化的事件驅(qū)動(dòng)代碼參見(jiàn)下圖。

圖-1事件結(jié)構(gòu)的圖形化代碼

對(duì)于事件結(jié)構(gòu)的基本知識(shí)介紹，這里將不做更多的講解。比較具體的講解和應(yīng)用我們將會(huì)在下一章：《LabVIEW圖形化語(yǔ)言的設(shè)計(jì)模式》中給出。

下面通過(guò)一個(gè)演示程序來(lái)進(jìn)一步理解事件驅(qū)動(dòng)編程。

例-1事件驅(qū)動(dòng)的演示程序

圖-2給出了演示程序的前面版。

圖-2事件驅(qū)動(dòng)演示程序的前面版

在前面版中，我們放置了三個(gè)控件。Door控件表示一個(gè)門(mén)（鼠標(biāo)點(diǎn)擊相當(dāng)于敲門(mén)）；Numeric控件用來(lái)紀(jì)錄事件的次數(shù)（敲門(mén)的次數(shù)）；Event控件用來(lái)停止演示程序的運(yùn)行。下面我們?cè)趤?lái)看看它的程序框圖。

圖-3事件驅(qū)動(dòng)演示程序的程序框圖

這里我們創(chuàng)建了兩個(gè)事件源，一個(gè)是：“DoorMouseDown”，用來(lái)響應(yīng)和處理用戶的敲門(mén)事件；另一個(gè)是：“EventMouseDown”，用來(lái)停止這個(gè)演示程序。

“DoorMouseDown”事件處包含3個(gè)Case結(jié)構(gòu)。

首次敲門(mén)，彈出對(duì)話框：“Hello!”；

第2次敲門(mén)彈出對(duì)話框：“Pleasedonotknockit!”；

之后再敲門(mén)將彈出對(duì)話框：“Iwillcall"110"”。

感興趣的可下載看看！

思考題：

在圖-3中的Case結(jié)構(gòu)中，“Case2”被設(shè)定為“Default”，這是為什么？運(yùn)行程序試試看，選擇Case0或Case1為默認(rèn)Case結(jié)構(gòu)會(huì)出現(xiàn)什么現(xiàn)象？

圖形化語(yǔ)言事件驅(qū)動(dòng)編程的特點(diǎn)

下面總結(jié)出事件驅(qū)動(dòng)編程的一些基本特點(diǎn)

事件結(jié)構(gòu)框架需與While循環(huán)配合使用

如圖-1所示，如果僅用單獨(dú)事件框架，那么無(wú)論有多少個(gè)事件源、產(chǎn)生多少個(gè)事件，該事件結(jié)構(gòu)也僅能響應(yīng)最先發(fā)生的那個(gè)事件。也就是說(shuō)：此時(shí)，只有一個(gè)事件會(huì)得到響應(yīng)和處理。

為了能夠順利地響應(yīng)多個(gè)事件發(fā)生，我們需在事件結(jié)構(gòu)外面加入一個(gè)While循環(huán)。有了這個(gè)While循環(huán)，我們就可以響應(yīng)和處理多次發(fā)生的事件，正如我們演示程序所示的那樣。

事件結(jié)構(gòu)的停止也應(yīng)采用事件處理方式

事件結(jié)構(gòu)中While循環(huán)的停止，也應(yīng)采用事件處理的方式完成。如演示程序中的“EventMouseDown”事件的處理方式。也就是說(shuō)，在程序執(zhí)行時(shí)用布爾常數(shù)來(lái)控制While循環(huán)的條件端來(lái)停止事件結(jié)構(gòu)。

圖-4停止事件也采用事件處理機(jī)制

事件結(jié)構(gòu)不宜處理耗時(shí)過(guò)長(zhǎng)的程序代碼

現(xiàn)在我們修改上面的例子，將事件處理中的對(duì)話框去掉，換成5s中的定時(shí)。參見(jiàn)下圖。

圖-5為每個(gè)事件處理加5s鐘定時(shí)

在例-5事件驅(qū)動(dòng)的演示程序中，我們?yōu)槊總€(gè)事件處理程序（每個(gè)Case結(jié)構(gòu)）都加入了5s中的定時(shí)。也就是說(shuō)，事件處理是需要一定的時(shí)間。如果事件連續(xù)發(fā)生會(huì)出現(xiàn)什么樣的情況呢？我們一同來(lái)看看。

運(yùn)行該程序后，我們馬上連續(xù)點(diǎn)擊3次Door，然后再點(diǎn)擊“Evert”。這時(shí)我們會(huì)發(fā)現(xiàn)，程序運(yùn)行了大約15s后停止下來(lái)。

這說(shuō)明，程序能夠響應(yīng)所有的事件，并陸續(xù)執(zhí)行完所有的事件處理。事件處理時(shí)間取決于各個(gè)事件處理時(shí)間之和。所以我們建議在事件驅(qū)動(dòng)機(jī)制中，事件結(jié)構(gòu)中不宜處理耗時(shí)過(guò)長(zhǎng)的程序代碼。因?yàn)?，我們通常希望看到快速響?yīng)事件及快速的事件處理。

事件結(jié)構(gòu)中事件處理不宜包含對(duì)話框

在圖-3事件驅(qū)動(dòng)中，我們使用了對(duì)話框來(lái)處理事件的響應(yīng)。實(shí)際上，在事件驅(qū)動(dòng)處理程序中這種方式是不可取的、應(yīng)該盡可能不用的。原因就是：對(duì)話框操作可能導(dǎo)致其它事件暫時(shí)無(wú)法響應(yīng)。因?yàn)椋绻麑?duì)話框沒(méi)有被及時(shí)處理，程序會(huì)一直停止在那里等待對(duì)話框處理結(jié)果。

實(shí)際運(yùn)行該程序我們會(huì)發(fā)現(xiàn)，在對(duì)話框彈