VFP 愛用者社區

Ruey · 註冊時間: 2003-03-12 文章: 1698 來自: tunglo 第 1 樓

資料來自：
為我指明正確之路(關於多資料集使用問題的解決方案)
作者：Paul Maskens 和 Andy Kramek
譯者：RMH
譯文出自：foxer 資料站（http://fbilo.myrice.com）

在你使用簡單的資料集時表單的資料環境是非常用有的. 在相同的表單必須使用位於不同目錄中的結構相同的資料集時就不得不使用一些技巧了. 當所要求的資料集的位置必須以參數傳遞時, 就更為困難—是不是? Paul Maskens 和 Andy Kramek 研究了該問題.

安迪: 你好, 保羅, 有一個問題要請教你. 我正在處理一個資料保存在標準的 Visual FoxPro 資料庫中的應用程式, 但是在不同的位置裏有多個這個資料庫的拷貝. (這是一個賬務應用程式, 它為不同的公司在不同的子目錄中各自保存一套資料). 我的問題是：我不得不創建這樣一個表單，把表單使用的資料集的位置作為參數在運行時交給表單。

保羅: 好, 要確信的一件事情是—你不能簡單的添加表到表單的資料環境並允許 Visual FoxPro 自動打開它們. 所有你傳遞到表單的參數在它的 Init() 方法中接收, 並且它的啟動晚於資料環境的初始化. 以下是表單運行時的事件順序:
1. DataEnvironment.OpenTables
2. DataEnvironment.BeforeOpenTables
3. Form.Load
4. DataEnvironment.Init
5. Form.Init
6. Form.Show
7. Form.Activate
8. Form.Refresh
9. Form.Gotfocus
安迪: 正確. 另外, 這個順序看起來有點奇怪, 不是嗎? 資料環境的 BeforeOpenTables 在 OpenTables 的後面激發?

保羅: 我同意, 但這僅僅是外表的異常. 我認為 OpenTables 是一個在 Visual FoxPro 基本類的代碼中調用的方法, 而 BeforeOpenTables 是一個在 OpenTables 方法被調用時激發的事件. 它實際上是一種實現 Hook pattern 的方法, 因此你可以包含代碼而不必直接添加它到 OpenTables 方法中. 當然, 這歸結於 Visual FoxPro 是如何管理打開表操作的. 看來在我們進行修改前要理解處理過程. 作為 Microsoft Office Automation with Visual FoxPro (《Microsoft Office 自動化和 Visual FoxPro 》Granor and Martin, Hentzenwerke Publishing, June 2000) 中的規定, “你不能自動化你不理解的東西”。

安迪: 好, 幸運的是, 一旦你搞清了因為“cursor”單詞兩種不同的用法而造成的混亂, 它就是相當簡單了。基本的處理過程是：首先 Visual FoxPro 添加一個基於 Cursor 基類的 cursor 物件到資料環境。接著, 它設置該物件的屬性，然後用這些屬性來創建真正的資料游標——就是我們用來進行讀寫操作的那個。至於相關的資料位置，我們需要擔心的只有兩個 cursor 物件屬性: Database 和 CursorSource。不幸的是，如表 1 所示，這兩個屬性被使用的方式取決於物件是引用自由表還是綁定表。最重要的是, 它是在設計時決定並在以後不能修改。

保羅: 喔, 但這意味著畢竟你可以使用資料環境. 由於這些屬性是在設計時設置, 你可以用它們來決定 Visual FoxPro 在何處找到它們並簡單的適當修改它們. 當然, 你需要設置 Auto-Opentables 為 .F. 來避免表被 Visual FoxPro 從它們的默認位置打開—但是在這種情況下只有一個屬性設置. 如果是事實, 你甚至不需要這樣做! 只需添加以下代碼到你的表單類的 Load() 中:
WITH This.DataEnvironment
IF .AutoOpenTables
.CloseTables()
ENDIF
ENDWITH
表 1. Visual FoxPro 如何保存資料位置.(譯者注: 本文中的綁定表即屬於某一資料庫的表)
表類型和位置 Database 屬性 CursorSource 屬性
綁定表, DBC 在本地驅動器 DBC 相對路徑和檔案名 DBC 表 “Name”值
綁定表, DBC 在不同驅動器上 DBC 的絕對路徑和檔案名 DBC 表 “Name”值
本地驅動器上的自由表 DBF 相對路徑和檔案名未使用
不同驅動器上的自由表 DBC 的絕對路徑和檔案名未使用
安迪: 寫得相當優雅. 它會在即使我忘記修改屬性時確保所有已經自動打開的表被關閉.

保羅: 是的, 但是對我來說還出現了一些東西. 在這些表單中, 關於綁定控制項到資料你怎麼做? 如果你在表單的 Init() 激發時還沒有打開任何表, 則你不能綁定任何控制項, 或者—你沒有東西綁定.

安迪: 問得好! 在它發生時, 我已經想過該問題了. 我計畫從表單的 Init() 中調用一個方法編程地綁定我的控制項.

保羅: 做得夠漂亮了. 因此現在我們達到在表單啟動時確保它不會打開任何表的階段了.因此我的第一個想法畢竟是錯誤的. 你可以把表放入到表單的資料環境, 我們所需要做的只是確保我們得到正確的表. 你是怎樣計畫傳遞到表單的?

安迪: 我想應該是我想定位的表所在資料庫的完整的路徑名和檔案名. 記住, 這是相同的表名用於不同的資料庫容器中的一種情況. 在這個特定的應用程式中, 各公司在他們的子目錄中的 DBC 中有一組表, 我會有一個表包括公司名字和位置及相關的資料庫容器的資訊. 然後用戶可以在登錄表單中選擇一個他們要處理的公司.

保羅: 因此, 在你的代碼中的某處可能會有象下面一樣的代碼行:
DO FORM frmMain WITH C:\Accounts\Data\TLC\CpyData.dbc
同時在你的表單的 Init() 你會這樣做:
LPARAMETERS tcDBCToUse
ThisForm.SetDBC( tcDBCTouse )
安迪: 有些東西是這樣的, 雖然我也考慮過使用這種方法, 由於這會從登錄表單中調用, 我會簡單地保存用戶選擇的路徑和檔案名到一個 application 物件的屬性或 _Screen 物件的屬性. 使用這種方法, 畢竟我不必傳遞一個參數也可以在表單的 Load() 中實際地獲取必須的資訊.

保羅: 好了, 那是一種辦法—如果你在表單的 Load() 中這樣做, 你也還可以使用綁定控制項. 事實上, 現在我認為, 這還遠不是最佳辦法. 你不必改變你的處理方法. 在你的表單類的 Load() 中簡單地放入代碼來強制關閉自動打開的表, 然後你可以象平常一樣用正確地使用資料環境. 你不必在表單的任何方法中放入任何代碼, 因此在子類表單類時也不會發生問題. 剩下要做的僅一的事情是編寫實際的代碼來改變資料環境中的設置. 我假定這應該在一個從表單的 Load() 中調用的你的表單類的自定義方法中.

安迪: 好象對於我來說這是合理的. 這些代碼非常一般—我們所要做的一切只是檢查 _Screen 物件上的已存在的特定屬性. (如你所知, 我不象你一樣使用一個 application 物件). 當然屬性會在登錄表單登錄成功並指定了資料庫時創建. 代碼是簡單的:
WITH _Screen
.AddProperty( 'cDataBase', ;
JUSTSTEM( ThisForm.txtDataBase.Value ) )
.AddProperty( 'cDataPath', ;
JUSTPATH( ThisForm.txtDatabase.Value ) )
ENDWITH
保羅: 打住. 為什麼你象這樣分開路徑和檔案名?

安迪: 喔, 那是因為這樣我可以在我需要明確地引用到沒有路徑的表時引用 database name 屬性, 考慮以下 SQL 語句:
lcDBC = _Screen.cDataBase
SELECT *;
FROM (lcDBC + "!Customers") ;
WHERE cust_id = liCurrentID ;
INTO CURSOR csr_CurCust
保羅: 但是僅在你需要在打開了多個資料庫時才需要這樣做. 對嗎?

安迪: 我不知道 <聳聳肩>. 但是為什麼要排除它呢? 除此之外, 如果我有任何自由表, 我會需要沒有 DBC 伴隨的路徑. 可能我的嘗試太巧妙了, 但是添加兩個屬性並分開它是很容易的. 在後來把它們組合在一起 (特別是現在 ADDBS() 是在語言函數中) 不是問題.

保羅: 我想你是對的. 事實上, 我確信你是正確的. 好了, 那麼, 我們已經檢查了_Screen 上面的屬性是否存在—可能使用的代碼象這樣?
IF ! PEMSTATUS( _Screen, 'cDataBase', 5 )
* 屬性不存在! Something is badly wrong
ASSERT .F. MESSAGE ;
"_Screen 的 cDatabase 屬性未找到" )
ENDIF

安迪: 幹得好—當然, 如果屬性真的不存在, 我們不得不趕快退出!

保羅: 現在對於實際代碼. 我們必須獲得資料環境中的所有物件的列表, 然後逐個檢查哪一個的 BaseClass 屬性是 Cursor. 找到時, 我們簡單地檢查 Database 屬性的內容 (對於自由表它總是為空) 然後因此更新 Database 或 CursorSource 屬性. 以下是可以直接放在 Load() 中或更恰當地放在一個從 Load() 中調用的一個方法中:
LOCAL ARRAY laObj[1]
LOCAL lnObjCnt, lnCnt, loObj, lcTable, lcDBC

*** 取得資料環境中的所有物件的列表
lnObjCnt=AMEMBERS(laObj, ThisForm.DataEnvironment, 2)

*** 搜索該列表
FOR lnCnt = 1 TO lnObjCnt
*** 檢查該物件是不是一個實際的 Cursor
loObj = EVAL( "ThisForm.DataEnvironment." ;
+ laObj[lnCnt] )

IF NOT ( loObj.BaseClass = "Cursor" )
*** 不是 Cursor - 忽略它
LOOP

ENDIF

*** 找到 cursor
IF EMPTY( loObj.DataBase )

*** 這是一個自由表, 取得它的 filename
lcTable = JUSTFNAME( loObj.CursorSource )

*** 添加正確的屬性
loObj.CursorSource = ADDBS( _Screen.cDataPath ) ;
+ lcTable

ELSE

*** 是一個綁定表, 設置 DBC
lcDBC = _Screen.cDataBase
loObj.Database = ADDBS( _Screen.cDataPath ) ;
+ lcDBC
ENDIF
NEXT
安迪: 它看起來相當優雅—但畢竟還不是非常優雅! 只有一個補充: 在最後, 我們是不是要重新打開表? 我們只需要調用資料環境的 OpenTables() 方法:
This.DataEnvironment.OpenTables()
保羅: 可笑的我. 我們當然要這樣做. 另外, 需然我在這些代碼中用了你的 _Screen 屬性, 當然我們任然會讓它成為可用的參數. 這樣它也可以處理我們剛開始討論的情況—從表單的 Init() 中調用. (該方法我會放入到我自己的代碼中). 因此我的最後的修改是用參數來處理整件事情, 象下面這樣:
LPARAMETERS tcDataPath, tcDataBase
IF EMPTY( tcDatabase ) AND ;
! PEMSTATUS( _Screen, 'cDataBase', 5 )
*** 無參數和屬性不存在!
*** Some is badly wrong
ASSERT .F. MESSAGE ;
"_Screen 的 cDatabase 屬性未找到" )
RETURN .F.
ENDIF
*** 使用傳遞的參數, 否則使用屬性
lcDataPath = IIF( ! EMPTY( tcDataPath ), ;
tcDataPath, _Screen.cDataPath )
lcDataBase = IIF( ! EMPTY( tcDataBase ), ;
tcDataBase, _Screen.cDataBase )
安迪: 太好了! 現在我要做的一切只是在代碼中用變數替換引用到 _Screen 屬性, 並且我有了一個真正的在運行時切換資料環境表的路徑的通用辦法. 謝謝你的幫助, 保羅.

保羅: 嗯! 我懷疑你是否已經可以自己做到這一點. 這是一個有趣的問題, 並且我認為在這裏我們有了一個相當好的方案. 實際可用的代碼在源代碼文件中的 PathSet.prg, 可從 http://www.pinnaclepublishing.com/ft 得到.

若需本文隨附程式，請與 RMH 或 FBILO 聯繫
03KITBOX.ZIP