如前所説，我們給Form的Caption賦値，從而改變了窗體標題欄的文字，給Label的Caption賦値，改變了標簽的文字。這裏，Caption就是所謂的“屬性”，每個對象都有它的属性，是它自己擁有的。

屬性，英文是property，是擁有所有權的東西（故也是私人財產的意思），引申爲專有的性質。不同的對象，都有屬於自身的性質（這就是“屬性”的來源），不同種類的對象擁有不同的屬性。比如，對人這個類，張三的腦袋跟李四的腦袋雖然都是腦袋，但卻是不同的兩個腦袋，所以，指稱對象的腦袋時必須明確説是誰的腦袋，這就是引用屬性時前面要加對象名的原因。另一方面，不同類雖然可能有相同名稱的屬性，但可能是完全不同的意義，正如我們看到，Form的Caption與Label的Caption表現不同。對各種不同的屬性，我們無法想當然，必須依據對象實際情況來理解，也就是説，我們應該瞭解它所歸屬的類——事實上我們認識事物也是從歸類開始的。

那麽，一個對象，我們如何知道它有什麽屬性呢？

在表單設計界面中，我們可以通過屬性框查看：

鼠標在對象上點擊一下，右側的屬性對話框就會刷新爲這個對象所有的屬性、事件和方法，翻查我們想要的，進行設置即可。雖然在這裏對話框中，每個項目的下方都有若干文字簡介其意義和用法，但明顯不夠，最齊全的資料就是幫助文檔（任何語言都是這樣的）。

在幫助系統中，每個(VFP內置的)種類都有詳細的清單：

我們平時就應該經常翻閲常用對象的這些資料，瞭解每種對象大概都有些什麽屬性、事件和方法，它們都是什麽意義、起什么作用的，寫個小程序測試一下每個項目的具體效果。學習的大部分時間，都應花在這個地方。

[此贴子已经被作者于2016-2-5 14:29编辑过]

屬性，雖然説是一種性質，描述性的，但其實它還是有行爲的。在語法上，我們看到無非是讀和寫，但其實，property是一種特殊的函數（方法），這點稍後再講。有一些屬性，除了改變內容，還附帶動作，比如Top，這是控件在容器內的頂坐標，當我們對它賦値時，並非僅僅把數値改變了而已，而是馬上有相應的動作，控件的頂部位置變化了，變到所指定的位置，這實際就是執行了方法動作，這不是一個値，而是一整套行爲。相對另外的一些編程語言（如C/C++），改變對象的字段變量，還需要自己主動調用對應的動作程序，才能把變化呈現出來，VFP不用這樣。

[此贴子已经被作者于2016-2-5 15:00编辑过]

事件(event)，顧名思義，就是一個特定事物的出現。比如，計時器計時到指定數、設備被插拔、鼠標點擊和鍵盤按鍵動作等，都是事件，Windows和VFP定義了一些事件發生時會傳遞消息，這些能够引起消息觸發和傳遞的事件，不是任意定義的，亦即我們無法自己定義事件（這點在事件能够接收的參數上明顯體現出來，事件的參數是固定的，無法增減），祇能使用系統內定的那些事件，但我們可以任意定義方法。方法(method)是執行一些動作，實際上就是普通的函數或過程。

當事件發生時，系統啟動相應的事件函數，並把指定的參數傳入，類本身有處理事件的特定行爲，我們可以在這裏增減動作，做比類設計多或少的動作，甚至讓程序廢除原先的動作而不動作。在設計器對應事件中寫代碼，就是我們要進行的獨特動作。正如“事件”這個名字告訴我們的，事件會在什麽時候被觸發，不是我們可以控制的，事件的發生，是任意的、無序的，比如你無法預知用戶會不會在不恰當的時刻點擊窗體的關閉按鈕而令你來不及儲存數據，你也不能期望用戶在點擊乙按鈕之前先點擊甲按鈕，同一個動作，他也可以不如你願地反复執行多次，這一點特性，是事件驅動程序與傳統面向過程代碼驅動程序設計的本質差異，正是這個差異，使編程思維翻天覆地的變化。

通常，事件的發生是被動的，也就是説，寫在事件中的代碼，什麽時候被執行、執行之後會引起什麽後果，都要我們事先考慮周詳。方法與此不同，方法是由我們主動調用的。這其實就是事件與方法的區別點，不過，屬性、事件和方法，界限不是那麽截然的，故而VFP幫助文檔都把它們放在一起，事實上它們也不是彼此隔絶的。有些事件，既是事件，也是方法，比如resize。事件的代碼，也是可以主動調用的，即哪怕它實際上並沒有發生，我們也可以用代碼調用那個事件函數，最典型的就是Init事件。

對象的方法，不僅僅局限於VFP內定的那些，絶大多數時候，我們都可以寫自定義方法，也應該多寫自定義方法。

[此贴子已经被作者于2016-2-5 16:44编辑过]

事件的触发的先后次序，对编程来说相当重要，下面是张洪举书中的资料：


这个事件触发的序列资料，应该抄录起来，随时能够查阅。实际上，它是有内在道理的，动脑筋想一下，也能理解为什么是这么一个顺序，而且为什么要设置这样一些事件，尤其是某些事件，看起来功能是差不多的。这点功课，就留给读者吧。吃透这一点，脑袋可以开一个大洞。张书的权威性，体现在这些东西上。

[此贴子已经被作者于2016-2-5 17:50编辑过]

VFP是內带數據庫引擎的事件驅動編程語言。面向對象編程模式是爲事件驅動而生的，Windows系統是基於事件的操作系統。事件驅動與代碼驅動的不同之處，是前者的嚮應流程是不確定的，它由近乎隨機的事件觸發每一個動作，由於不能假定事件之間的發生是有次序和必然邏輯的，所以它每一次應答，都應該相對獨立，難以依賴前後動作；後者則不同，程序的過程幾乎是固定的，所有動作都在代碼安排之下，幾乎不受事件打斷。簡單地説，事件驅動編程思想的立足點或世界觀，是這個世界不由我決定，是我適應環境，代碼驅動編程思想則是世界在我掌控之中。這幾乎是對立的世界觀，一般説，程序員傾向於接納與自己哲學觀點相同的方法論，事件驅動可歸於客觀主義，代碼驅動可歸於主觀主義，事實上，觀察程序員的編程傾向，的確可以發現他做人處事的哲學態度，往往是與此相符的。

事件驅動，由於出發點就不預測程序從那裏開始、路徑如何，所以它通常總是處於等待狀態（與控制臺或命令窗口的等待不同，控制臺是等待指令，但事件驅動程序是等待各種事件的發生，接獲指令祇是事件之一）。故而，這類程序的主體控制結構，必定是死循環，永遠在“空”轉，循環之中不斷地檢測內定的事件是否已被觸發，如果觸發，就把該消息發送給設計好的處理該事件的模塊，對應的模塊處理好之後，把結果消息返回給主控循環，主控循環再根據其反饋決定下一步流程。

熟悉Windows編程的人都知道，Windows程序就由兩個程序段組成，一個是主控死循環，它就是在空轉檢測消息，另一個是消息處理程序，前者把檢測到的消息發給後者進行處理。如果這樣的程序不是死循環，那麽程序把事件應答處理完，就會自動結束，這就是“一閃即逝”現象的原因。當VFP啟動了一個窗體(Form)之後，如果不接著啟動一個死循環把自己留住，就被操作系統回收了——所有在Windows下編程的IDE中啟動cmd窗口運行控制臺程序結束之後要附加一個等待按鍵的動作也是這個原因，因爲其宿主cmd窗口在程序結束後被操作系統沒收了。

VFP的機制與此相同，故而若啟動的Form不是模式窗體，那麽就必須在啟動Form之後，用READ EVENT指令開啟“事務處理”流程，這個所謂的事務處理，其實就是Windows程序要求的那個死循環。

因此，在VFP中，若是用DO FORM指令開始的表單程序，此表單必須是模式窗體，否則它會一閃即逝——在VFP IDE Screen中，它已把控制權交還Screen；若編譯後脫離VFP執行，則是一閃即逝。故而，若表單不是模式表單，則必須用代碼在DO FORM之後再加一句READ EVENTS，這就是有時必須用PRG啟動程序的原因。若是直接從表單啟動程序，由於沒有合適的辦法在表單某個事件之後啟動事務處理流程（時序上在READ EVENTS之後的代碼必須在CLEAR EVENTS之後才會接續執行，而在表單的事件中，沒什麽事件是可以讓你這樣掛起的），這是很多初學者都會遇到的問題，而不少人“學到”之後，也是不大清楚問題到底是如何解決的。

在表單外READ EVENTS，在表單內CLEAR EVENTS，這是必然的邏輯。

[此贴子已经被作者于2016-2-8 19:00编辑过]

模式表單是當前進程内常駐前端的窗體，除非主動關閉，它會一直處於激活狀態，亦即AlwayOnTop屬性的意義。當進程衹有單窗體時，設其爲模式表單就是要主動關閉才能結束的意思，此時已經處於read events的狀態。

模式表單衹對當前進程有效，事實上仍然可以使用系統任務切換功能切換到其他進程。

不値得繼續。

https://bbs.bccn.net/thread-463047-1-1.html
幫不了人就不值得咯，讓人視而不見也不值得咯。