不管在 master 或是 detail, 在 Foreign Key 上的輸入, 並帶回相關的 lookup 資料, 不外乎幾個方法:    1. 如果用戶習慣記憶編碼, 則提供直接輸入 Foreign Key 欄位 2. 如果嫌鍵值編碼不好記,或者它根本就是個無意義的 IDENTITY/AutoInc 型,那麼提供一個按鈕、一個小小的 Lookup 畫面,即能帶回 3. 對於筆數少的情況,用 DBLookupComboBox 也很方便    問題來了... 如果客戶要求在 lookup field 上輸入,然後在按 Enter 之後即可帶回其他欄位。這該如何是好?    舉個例, 在出貨明細, 他就是不要你在 [產品編號] 上面下功夫, 他偏要在原本lookup 帶回的欄位上, 例如 [產品名稱] 輸入, 然後按 Enter。 以 partial match 檢查是否有多筆... . 若只有一筆, 則直接帶回其他欄位 . 若有多筆, 進一步開個小 dialog 詢問這幾筆記錄, 要選擇哪一筆?    其實我也覺得這樣輸入還蠻人性化的, 但我遇到下列的問題...     1. 基本上 [產品名稱] 原來是lookup field 沒辦法鍵盤輸入的 2. 如果我改成在 dataset 就 Join 兩個 table, 那麼由於增刪修的操作, 雖能對 [產品名稱] 輸入, 但難免改到 [產品基本資料], 這不是預期中的目標 3. 如果在 master 我就好辦了, 弄個 TEdit 去讓它輸入就好了, 不要用 TDBEdit。但在 detail 由於只有一個 DBGrid, 我又技窮了... 各位能否指點迷津? Jimmy Gump 發表人 - jimmygump 於 2004/12/06 22:03:19

------
Jimmy Gump

同樣在別的 detail 的 DBGrid 中 "選擇 [會員]" 的場合也一樣。 他偏不在 [會員編號] 上面做 lookup, 而是在 [會員名稱] 或 [會員生日] 上面做輸入。 Jimmy Gump

------
Jimmy Gump

to jimmygump:   像這種有foreign key的欄位輸入,我都會在旁邊放一個小按鈕.如果使用者記得代碼,可以在TDBEdit裡直接輸入,如果不知道,那麼可以點這個小按鈕,然後就會以ShowModal的方式跳出另一個查詢視窗,直接把所有的reference的table,所有的欄位及資料都show出來.在視窗中user可以設定若干個任意欄位的過濾條件去找到使用者要輸入的資料.這樣,user要怎麼去找到他要輸入的那筆資料,都可以去做.    例如下例,使用者要輸入商品編號(如下圖),我會在旁邊放個TSppedButton(就是有"..."的那個按鈕) 當user點選下去後,會跳出另一個視窗,把所有user可能會輸入的商品基本資料找出來,讓user自已去找到他要的資料(如下圖,就是資料查詢那個視窗) user點選後,就會把點選的該筆資料,相關的欄位帶回使用者輸入的component內. 我所有的Foreign key都是這樣做,這種寫法很費力,必需要好好管好程式,盡可能的把程式碼物件化,不然維護起來會很累,不過效果不錯.參考看看

引言: to jimmygump: 像這種有foreign key的欄位輸入,我都會在旁邊放一個小按鈕.如果使用者記得代碼,可以在TDBEdit裡直接輸入,如果不知道,那麼可以點這個小按鈕,然後就會以ShowModal的方式跳出另一個查詢視窗,直接把所有的reference的table,所有的欄位及資料都show出來.在視窗中user可以設定若干個任意欄位的過濾條件去找到使用者要輸入的資料.這樣,user要怎麼去找到他要輸入的那筆資料,都可以去做. 例如下例,使用者要輸入商品編號(如下圖),我會在旁邊放個TSppedButton(就是有"..."的那個按鈕) 當user點選下去後,會跳出另一個視窗,把所有user可能會輸入的商品基本資料找出來,讓user自已去找到他要的資料(如下圖,就是資料查詢那個視窗) user點選後,就會把點選的該筆資料,相關的欄位帶回使用者輸入的component內. 我所有的Foreign key都是這樣做,這種寫法很費力,必需要好好管好程式,盡可能的把程式碼物件化,不然維護起來會很累,不過效果不錯.參考看看

是啊，我也都是這樣做的。 問題是．．．他就是 "不要在編號上下手" 嘛。 他希望在其他 lookup 出來的欄位上直接輸入的耶，例如，在 [品名]或[規格]上直接輸入，就要我可以採用 partial match 方式帶出(當然同時會帶回 [品號])。 他非常抗拒所謂 "按...按鈕跳出一個 ShowModal 的小窗"，因為他認為多此一舉。 我實在很難去跟他解釋所謂 Foreign Key、Lookup Field 和 Data Field 的不同、．．．等等比較技術性的東東。只能說，他的需求也不無道理，甚至，我自己都覺得 "對哦，我寫十幾年程式了，怎麼沒想過這樣輸入比較直覺？" 唉，有點煩 Jimmy Gump

請問一下: 1.視窗的大小就是那麼大,可以顯示的資料就是那麼多.如果不另用一個視窗輸入,那畫面夠大擺下那麼多輸入的component嗎? 2.在lookup的欄位直接輸入,那請問,程式怎麼知道他是要輸入品名或規格或編號或是其他的搜尋欄位?如果要為每個他可以輸入的欄位去放個component讓他輸入,那要多少個component?再者,如果他在品名輸入的值,符合條件的資料超過一筆以上,勢必也要user去點選,程式也不可能幫他判斷吧,既然要選,也勢必跳出另一個視窗讓user點選,如果不另跳視窗,那怎麼辦? 突然想起現在的客戶,也是"澳客列傳"裡的,老是一些奇怪的要求.... <>< face="Verdana, Arial, Helvetica">引言: 是啊，我也都是這樣做的。 問題是．．．他就是 "不要在編號上下手" 嘛。 他希望在其他 lookup 出來的欄位上直接輸入的耶，例如，在 [品名]或[規格]上直接輸入，就要我可以採用 partial match 方式帶出(當然同時會帶回 [品號])。 他非常抗拒所謂 "按...按鈕跳出一個 ShowModal 的小窗"，因為他認為多此一舉。 Jimmy Gump

Dbgrid ->onTitleClick 帶出一個TEdit, Edit按下enter後 根據 OnTitleClick取得Column->取得Field 根據Edit的值作Filter...

非常感謝各位的指導~    這幾天我有一些省思: 1. 我們習慣在 Foreign Key 的 Data Field 上去做 lookup, 而非 Lookup Field 上去做。然而, 這真的是我們技術上的考量而已。 2. 撇開 Delphi 目前的限制不談, 沒有人告訴我們, 這種需求有何不可?    就像我之前做的, DBGrid 按 Title 就可以排序, 我用的是 ADO 的 .Sort 屬性直接重排。這樣的實作同樣遭遇技術瓶頸---".Sort 是不能指定成 fkData 型態以外的欄位的"。於是 DBGrid 裡, 只要是 fkLookup, fkCalculated 的欄位, 我都設定成別的顏色, 而且讓它的 title 按了也無效。客戶驚呼: 怎麼可能? 應該要全部都可以排序啊...那為什麼其他欄位都可以排?.... 呵, 我也知道最好是全部都可以啊, 想聽原因, 倒是可以從 dataset、field分為三種 fkData, fkLookup, fkCalculated、DataSource、DBGrid...層層解釋, 但...客戶對我的解釋完全不能理解,同樣的,我自己也很難接受這樣的事實,畢竟,需求是有理的,而開發工具的限制也正在受這些一般所謂澳客的挑戰... Jimmy Gump 發表人 - jimmygump 於 2004/12/07 11:34:33

------
Jimmy Gump

引言: 非常感謝各位的指導~ 這幾天我有一些省思: 1. 我們習慣在 Foreign Key 的 Data Field 上去做 lookup, 而非 Lookup Field 上去做。然而, 這真的是我們技術上的考量而已。 2. 撇開 Delphi 目前的限制不談, 沒有人告訴我們, 這種需求有何不可? 就像我之前做的, DBGrid 按 Title 就可以排序, 我用的是 ADO 的 .Sort 屬性直接重排。這樣的實作同樣遭遇技術瓶頸---".Sort 是不能指定成 fkData 型態以外的欄位的"。於是 DBGrid 裡, 只要是 fkLookup, fkCalculated 的欄位, 我都設定成別的顏色, 而且讓它的 title 按了也無效。客戶驚呼: 怎麼可能? 應該要全部都可以排序啊...那為什麼其他欄位都可以排?.... 呵, 我也知道最好是全部都可以啊, 想聽原因, 倒是可以從 dataset、field分為三種 fkData, fkLookup, fkCalculated、DataSource、DBGrid...層層解釋, 但...客戶對我的解釋完全不能理解,同樣的,我自己也很難接受這樣的事實,畢竟,需求是有理的,而開發工具的限制也正在受這些一般所謂澳客的挑戰... Jimmy Gump

Jimmy Gump

>>---".Sort 是不能指定成非 fkData 以外的欄位的"。 反正規化.... 例如訂單中用客戶編號來lookup客戶名稱 把客戶名稱的欄位也加入訂單中 奧客肯出錢support你修改,那應該是在可以接受的範圍

引言: >>---".Sort 是不能指定成非 fkData 以外的欄位的"。 反正規化.... 例如訂單中用客戶編號來lookup客戶名稱 把客戶名稱的欄位也加入訂單中 奧客肯出錢support你修改,那應該是在可以接受的範圍

呵, 奧客就是奧客, 想加錢也是白搭的啦~~ 想到古早寫 Clipper, 真的不要跟客戶說什麼 "做不到", 因為...沒有元件, 凡事自己硬幹都 ok 的。現在呢? 若叫我不要用 DBGrid, 改用別的什麼亂七八糟 Grid 硬做出來, 我都還嫌麻煩...算了算了 Jimmy Gump

如果你的客戶數多,那麼,用元件應該可以有不錯的效益 因為我一直在想,delphi的這種架構,可以很彈性的設計元件 而且老外也蠻多銷售3-party元件的公司, 這應該是有其經濟規模的效益可以預期... 如果我們也能辦得到的話, 當然,元件的設計必須要立足於實用與現實狀況... 這就需要實際接觸客戶的經驗了...