VFP 愛用者社區

reterjang · 註冊時間: 2006-04-19 文章: 5 第 1 樓

請問各位愛用VFP 的高手，小弟我用VFP 9.0 SP1 寫了一個公司要用的工時資料建立作業程式，在程式撰寫的過程中就有偶爾會出現Fatal Error的視窗，然後整個VFP 就當掉了..
Win XP就會強制關閉VFP..
原本想說只是出現幾次不以為意，想不到程式都寫好安裝到User的PC了..
卻非常容易跳出Fatal error的狀況，程式當掉重新執行後又沒問題了..
過一陣子又會再來一次，真的很傷腦筋 ..
不知有沒有VFP的老手在使用VFP 9.0 SP1 時有遇到同樣的情形..

朱育興 · 發表於: 星期二七月 10, 2007 12:26 pm 文章主題:

沒遇過，SP1 出來我們就立刻用，大致情形都 OK，沒有你說的情形發生過

impotence · 發表於: 星期二七月 10, 2007 12:44 pm 文章主題:

希望這段在網上找到的文章 , 對你有點幫助 ...

c0000005錯誤發生的誘因主要分爲四大類：

1、自由表存儲載體的缺陷(主要體現在VCX、VCT，SCX和SCT上)。
2、第三方監控性質的軟件(如：防毒軟件在內存即時監控狀態下、詞霸在全屏拾取模式下等)；
3、Visual Foxpro 自身的代碼漏洞；
4、硬件因素。

先說第一大類：

同數據表一樣，在Visual Foxro 9.0 版本中，自由表也支持了原子事務機制，這幷非主要是爲了滿足客戶的需要，而以穩定VFP9自身爲主。我們都知道類與表單的代碼多以物理形式爲自由表的VCX、VCT，SCX和SCT文件格式存儲，在IDE設計模式下，代碼被VFP後臺以獨占的、開放式自由表緩衝的模式存取。然而您應該敏感地注意到：自由表是不支持事務機制的(低于9.0版本的Visual Foxro)。也就是說，遇到停電或操作系統异常時，它們同樣會面臨表頭損壞、低級鏈接錯誤、記錄指針錯誤偏移的風險。Microsoft Visual Foxpro 開發組沒有將VCX、SCX設計爲依賴于數據庫的數據表的形式，原因不難理解——如果一個表單文件中，包括表單本身在內的任何一個控件都不依賴于用戶自定義派生類的話，那麽該文件應該可以被獨立地拷貝與打開。

如下的常識我們都需要知道：

無論是在設計模式還是在運行模式下，Visual Foxpro的Runtime會隨時將客戶脚本讀取到內存體中，幷交由詞法分析器、語法分析器和語義分析器來分析、解釋、處理這些代碼。

(通常情况，在編輯模式下，我們的脚本代碼已經被Visual Foxpro詞法分析器進行了第一遍的過濾；在編輯完一個prg或表單或類文件後，若按下Ctrl+W組合鍵將在保存它之前調用語法分析器來試圖檢查其中的錯誤(注意“詞法”分析器與“語法”分析器的不同)，然後程序界面將自動被關閉；而若按下Ctrl+S組合鍵保存後，再手動退出時，這種情况下將不會調用語法分析程序。)

如果你的脚本保存在自由表形式的SCX、SCT、VCX、VCT文件中，Visual Foxpro會通過表的記錄指針提取對應備注文件裏的程序脚本(那裏或許包含了某些事件或方法的代碼)。首先，Visual Foxpro 的底層通過調用C語言的sizeof()來判斷字節的長度，根據長度提取字節，將其存放到字符類型的數組中，最後將長度的返回值與該存放實際代碼的數組以參數的形式傳遞給語義分析器來解釋執行。然而在一些情况下，會發生sizeof()判斷的字節長度與實際的長度不一致的情况。

倘若sizeof()判斷的字節長度與實際的長度不一致，將會發生內存的溢出，這個致命錯誤被Visual Foxpro异常處理器捕獲後，將拋出“致命錯誤－C0000005”的信息。

“致命錯誤=”是字符常量，“c0000005”是一個變量，c0000005不是VFP的錯誤編碼，而是得到Windows消息環所傳遞過來的錯誤消息參數的半加工品。它的原始狀態是16進制的0xC0000005，VFP通過相關的轉換函數轉換成字符串的形式，以便通過界面描述給用戶。

那麽什麽情况下會出現sizeof()判斷的字節長度與實際的長度不一致的情况呢？主要有兩方面的主導因素。

1、我們前面鋪墊過了，VCX、VCT，SCX和SCT文件都是自由表，都有可能在設計時被無意的損壞。

倘若表頭被損壞，您會在試圖打開它們的時候收到VFP系統的無法打開該表單的信息；但倘若低級鏈接錯誤、記錄指針錯誤偏移，您就不會得到任何VFP的提示，因爲VFP系統自己也不知道這一點，就像您一樣。于是直到程序運行時，才會收到令人驚愕的致命錯誤信息——語義分析器工作時內存被溢出。

在一些“致命錯誤－C0000005”的信息框中，您會收到似乎更詳細些的信息，指示您程序出錯的地方。那通常是包含在SCX、SCT或VCX、VCT裏某些行的代碼。

千萬不要被誤導，幷不是您的程序代碼編寫有問題，而是隱藏在標識符之外的、看起來好像是空格、回車的空白段，那裏隱藏了低級鏈接的錯誤、或Unicode的錯位排序(下面馬上就會講述到)，用Shift+方向鍵將整行全選，然後按Delete鍵删除之，最後老老實實地將原行代碼重新書寫一遍即可(切記：用Shift+方向鍵將整行全選，然後將該整行徹底清除)。

2、Unicode

從Windows98升級過來的VFP程序員似乎都曾有過這樣的困惑：爲什麽Windows2000以上版本的VFP程序會如此的不穩定，以至于頻繁出現“致命錯誤——C0000005”？

Visual Foxpro的詞法掃描器大概是這樣工作的：詞法掃描器分析代碼脚本的時候，先要判斷一下下一個被掃描的Token是否爲空白標記。若是，則看該空白標記是Tab標記還是回車標記，或者是分隔符或其它的占位符；若不是，則判斷該Token是單字節還是雙字節字符，這種機制在基于Unicode的Windows版本中，有時會遇到標識符號的錯位。

您現在上網用的計算機的操作系統是WIN2000或WinXP嗎？如果是，不妨親自做這樣一個試驗：

打開記事本程序，輸入“聯通”，然後保存後關閉該文本，再重新開打，看到什麽了？標識符號被錯位了！

是的，當年WIN2000操作系統的流行時，Visual Foxpro開發組幷沒有徹底改正語義分析器代碼的漏洞。
好的，第一大類我就闡述完了。如何避免它呢？

總的應該說很麻煩，有兩種途徑供您選擇：

1、修改VCX、SCX表國際代碼頁的編碼，將簡體中文編碼改爲英文編碼；

2、我所推薦的方法是儘量用prg。你可能會認爲這樣做很麻煩，但作爲程序員，您應該更加專業一些。您可以備份可視化的表單或類文件，但在程序正式發布前，最好最大限度地轉化爲prg程序。倘若以後需要修改程序，通過備份的表單或類文件進行可視化編輯，然後再次轉化爲prg發布之。

對于已經開發好的項目，就沒有必要大興土木地全部將Vcx、Scx轉化爲Prg了，但您應該著重關注一下主菜單Mnx文件，及控件(尤其是圖片)特別多的表單。或許，您曾遇到過這樣令人匪夷所思的問題：在運行exe文件時，爲什麽有時候一切正常，而有時候却産生致命异常——要知道開發人員根本就沒改任何的代碼呀？

下面我將剖析上面的問題：

在用菜單編輯器進行菜單定義時，Visual Foxpro系統將産生四個對應文件：一個自由表、前者的備注文件，一個程序文件(mpr)及它的執行格式文件(mpx)。

如果您用 Do Menu XXX.mnx 的方式調用主菜單時，.mnx與.mnt兩文件將被包含至工程中去，在exe執行時，以提取自由表記錄的形式解釋程序。

但mnx模式存在著一個致命的缺欠，就是Visual Foxpro 在申請堆棧時的預定空間量相對prg的程序文件要小許多。通常這沒什麽問題，但你要知道幷不是每次Visual Foxpro 都能如願地向Windows操作系統申請到預定的空間值，有的時候它所獲得的堆棧數目會少一些，甚至恰巧會小于菜單初始化時所需要占用的空間量。這就是爲什麽有時候exe第一次運行時正常，退出後再次運行時偶爾會出現“致命錯誤－c0000005”的原因。

請您以 Do XXX.mpr 的形式直接調用程序文件形式的mpr，就能够很好地避免之。因爲在默認情况下，Visual Foxpro 爲程序文件所申請的堆棧數遠遠大于mnx，即便是Visual Foxpro沒有從Windows操作系統中得到預定數目的空間，然而比起定義存儲prg內脚本的字符型數組的長度來說，也綽綽有餘了。

另外，一個存儲了大量控件與圖片信息的表單，同樣會遇到與菜單文件相似的情形——即Visual Foxpro 所獲得的堆棧數小于表單初始化時所需要的數目，從而造成內存的溢出。

順便告訴您一個小竅門：

在IDE設計模式下，我們或許會突然遇到“致命錯誤－C0000005”襲擊，因爲表單是以獨占的、開放式自由表緩衝的模式交互的，所以此前未經保存的信息都將被丟失，這您是知道的，通過剛才的講述，您還知道了這或許會面臨表被損壞的風險，從而進入了一個“致命錯誤－C0000005”潜在引發今後“致命錯誤－C0000005”故障的惡性循環。

小竅門就是，您千萬不要條件反射地去觸擊那個“確定”按鈕！那不過只是Visual Foxpro系統所捕獲的异常罷了，它不是真“致命”的，Visual Foxpro系統仍在運轉中，也就是說，它還在正常地接收著Windows操作系統不斷發送來的消息。這時，請您點開Windows桌面最左下角的“開始”按鈕，選擇“重新啓動計算機”或“關閉計算機”，Windows在試圖關閉電腦前，會先檢查是否有尚在運行中的應用程序，它會發現一個叫Fox的先生尚未退場，于是便發送清場的消息給Foxpro，Visual Foxpro其實還在正常的運轉中，它接收到這條消息後，會調用自身的退出機制試圖退出，而自身的退出機制會發現尚有正在編輯的表單，便會發出“需要保存修改嗎？”的詢問消息，這時候，您選擇保存，就可以了！

千萬注意了！這段過程大概只有5秒鐘的時間！因爲爲了防止死循環的情况出現，Windows會在等待幾秒鐘對方不應答的情况下强行終止程序，那時候，就真正退出整個Windows系統了。所以您一定要眼疾手快！

第二大類是第三方監控性質的軟件。如：防毒軟件在內存即時監控狀態下、詞霸軟件在全屏拾取模式下等。其實防毒軟件本身幷不與VFP産生衝突，但有一個例外，就是內存即時監控(請注意：防毒有許多即時監控，唯有內存即時監控才會與有時候與VFP發生衝突)。

所謂內存即時監控幷不是去讀取內存條中的數據，誰也沒這麽大的本事，它的原理就是專門關注于Windows系統目錄下的system32子目錄中的程序文件在運行中的狀態。

我們知道，在Visual Foxpro 8.0 版本以前，其運行時刻文件是安裝在system32目錄中的；而向最終客戶發布你的應用程序時，默認情况下，無論是VFP什麽版本，其運行時刻文件均會被拷貝到system32目錄中去。

防毒軟件的內存即時監控的工作原理是這樣的(這是瑞星公司首創的，瑞星軟件也是狐友受害最深的)：1、它會在Windows後臺運行一個類似于Windows的模擬機(這有點像任天堂游戲模擬機和一些手機模擬機，還有現在時髦的Linux下的Windows模擬機)；2、它運行一個循環，挨個監視system32目錄下的exe及dll文件是否被調用；3、倘若被調用，就拷貝一份到瑞星自己創建的隱含、系統目錄中去，然後在那個模擬機中運行之，以便模擬其在Windows實際運行中的狀態；4、在模擬運行中，看它是否有病毒發作的特徵；5、如果有，就查找病毒特徵碼數據庫；6、若在數據庫中，找到了對應的特徵碼，便確定特徵碼所對應的病毒名稱，否則，就按未知名的新病毒處理(這就是爲什麽有的VFP加密軟件會被防毒軟件誤報病毒)。

由于VFP應用程序與運行時刻DLL庫交互的太頻繁了，使防毒軟件的那個循環程序不斷捕捉到VFP運行時刻庫在進行新的數據響應，防毒軟件便不斷地試圖拷貝它，以便進行新一輪的模擬。但你知道，無論是DBF還是SCX等等，只要是獨占方式打開的(SCX與VCX總是被獨占的，而DBF取决于你的設計)，就不能被其它的程序所訪問。但在Windows操作系統中，防毒軟件所調用拷貝程序的系統優先級要高于你的程序的優先級，所以有時你的VFP程序會最終産生致命錯誤。

如何避免呢？你可以簡單地關閉防毒軟件，但如果讓客戶也像你這樣做的話，就有霸道之嫌了。

聰明的你恐怕現在已經想到了：只要在發布你的應用程序時，將那些運行時刻庫放到應用程序目錄下就可以了！

同樣，詞霸軟件本身也不會與你的程序發生衝突，只是在全屏取詞的模式下才會如此。不過你的用戶幾乎不會遇到，因爲你的程序幾乎不會讓他們在程序界面狀態下直接打開某個數據表——僅在詞霸的全屏取詞程序試圖通過獨占模式下的數據表的窗口句柄，來訪問裏面的文本屬性時，才會與其獨占模式發生衝突。

第三大類是Visual Foxpro 自身的代碼漏洞。比如VFP6.0版本的Textbox控件等等。現在版本的VFP，這樣的錯誤少多了。關于Visual Foxpro 自身的代碼漏洞導致c0000005异常的話題，早已被論壇上諸多的高手反復總結過了，我們的話題就不再展開了。

第四大類是硬件因素。

有些細節問題是最不被人所注意的。但其足以鑄成大過。

“致命錯誤C0000005”是內存泄漏的症狀，而不僅僅是內存溢出、除零(這就是Visual Foxpro 自身的代碼Bug所導致的結果)，還有一個原因就是申請到的堆棧意外不足。

在用電高峰期(例如夏季、或晚間的黃金時段)，電壓的突然不穩定，或許會非常微小，不至于迫使計算機意外重啓，但或許會導致VFP系統在通過Windows消息機制向內存體申請堆棧時，得到Windows意外的反饋。

除了說服您的客戶使用UPS外，您應該檢查用電的負荷情况，比如檢查打印機或臺燈是否與計算機電源綫一起接在一個多功能插座上，應該儘量避免這樣，一些老式的打印機，在打印作業時會消耗很大的電流。

Erwin · 發表於: 星期二七月 10, 2007 12:46 pm 文章主題:

是不是有用到備註欄位的edit, 有的話請搜尋一下舊資料解答

reterjang · 註冊時間: 2006-04-19 文章: 5 第 5 樓

感謝 impotence 提供那麼詳細的資料，我會好好的研究一下.

To Erwin
我的確有用到滿多edit在備註欄..
多謝提醒，我再回頭找資料..

syntech · 發表於: 星期三七月 11, 2007 11:00 am 文章主題:

VFP6 的 editbox BUG ,好像 VFP 8.0 已經改好了.