如果是我做維護，就斬斷這個變量，直接在該處實現目的，實際上這個東西不需要用全局變量傳遞的。還是前面說過的，這個系統在設計上很成問題，非常有問題。拿別人的項目研究不是不可以，但最好找個較好的。

[此贴子已经被作者于2015-11-6 21:26编辑过]

根據截圖看到的現象，最後宏代換出來的字符串中包含一個&符號，顯然是在夾雜在某處字符串中帶過來的。

可以做一個追蹤控件監視這個變量是否被改變，一旦被改變，會觸發事件，這樣就能知道在哪裏出問題。

楼主，知道这个例题最致命的错误在哪里吗？就是表文件的设计！我不知道书的作者需要如何计算这些成绩，但我至少知道这种表格结构应该是统计表的格式，而不应作为源数据的表结构。我看到这种结构的表文件设计，就知道那书的作者对于什么是“源数据”，源数据表的结构应该如何科学地设计方面也是空白的。

我哪知道什么项目好　　什么项目不好啊　　　


要不然　　你给我发个项目　　　带说明教程的



或者　　　你给我推荐一本书　　　　我去买来看看　

[此贴子已经被作者于2015-11-7 08:06编辑过]

没那么深研究表结构呢

和8楼说的　　貌似是一回事


不过　　表单自定义属性　　没研究过　　　看过的书里　　没有讲过　

在表单设计器，菜单中的“表单”项里就有创建和编辑自定义表单的属性和方法。
对于VFP来说，一定要掌握好类的设计和引用，少不了涉及到属性、方法和事件，表单也是一个类哦。

用較簡單的小項目，如學院教學最常用的畢業設計學籍管理、通訊錄之類，先設想一個需求，然後實現它。其實，項目需求的東西，想做簡單可以，做複雜也可以，別以爲通訊錄很容易，隨著需求的變動，要多難都會有（吐槽一下我見那些學生做課設交出來的作業真是不忍卒睹，不知道他們的老師怎麽判合格標準的）。用自己職業上需要用到的，是最好的項目，想要達到什麽目的，自己最清楚。

先定需求，再做設計，最後才是編碼。軟件工程上有一個大概如三三制的理論，即這三部分，各佔30%的時間，編碼佔比較次要的地位（很多程序猿自視過高是沒有擺正身份不明白這個道理）。需求不清就動手寫程序，那是失敗的居多。

也可以用你這個項目做例子。這個項目把所有科目的成績都放在同一張表上，我不看後面的，可以猜測程序實現是指定某個字段是什麽意義的，要“數學卷一成績”，就在代碼中寫SX1，絕大多數人都會這麽做。這是一種需求下的設計，那麽我給你變動一下需求（需求變動是現實中很常見的事），現在學校需要增減一些科目，你可以在腦中想象一下，原先的設計方案，需要改動的地方有哪些？好，你說現在這個客戶未來是不會變動科目的，那麽，如果你是賺外快給多所學校做同樣功能的程序呢？每個學校都會不同的科目設置，你針對這個學校是這樣寫，針對那個學校是那樣寫，到時外快賺多了，有一百來個學校，你這些版本不同的程序都維護得過來嗎？這其實仍然是需求，是你自己方面的需求，你絕對不會願意分別維護這許多大同小異的程序，必定會想當初如果寫個適應性強的版本就好了，在代碼不硬編碼“數學卷一成績”對應SX1，而是另外做一張對應表，衹要在外面修改這張表，就滿足不可知的變動，而呈現出來的界面，是統一的，行爲也是統一的。這麽一來，你的程序實現手段會來個大顛覆，幾乎把原先的系統推倒重來。所謂實踐經驗，是你有沒有碰過這類看似小變動，實質要傷筋動骨的問題，給人寫任何程序，都預防了出現這種情形，那樣才不會搞到自己。這樣的釘子，一定要碰過才知道別人這般告誡的價值，很多學生是聽不進去的，他們覺得現在實現了要求的功能，就是可以的，故從來沒有培養寫程序要應付未來變動可能性的意識。

再說了，原來那表，把總分和分卷分都獨立成字段，彼此地位一樣，但對計算機來説，總分是可以臨時計算出來的，設計獨立字段沒有必要，屬於冗餘數據，分卷分變動，代碼中就得附帶修改總分字段的尾巴，原作者那樣設計表結構，是爲了寫Grid界面時方便，但其實是無形中增加了代碼另外的複雜性，比如要特意設置這個字段是衹讀的、位數也要加大一級等等。如果是我做，我可以在Grid控件任意添加表沒有的欄，不需要在物理表上有這樣的字段。所以，一看到這樣的數據表結構，就知道他的設計思路是什麽，有什麽問題，也能預計它會在什麽時候、什麽地方出現問題。

你不要以爲用向導替你做Grid控件自動設置好字段欄目之類很得意，像這個表設計，SX=SX1+SX2，那是硬編碼，代碼中人腦記住SX對應，一個科是一行，有多少科就多少行，向導不會替你生成哪個字段加哪個字段填到哪個字段，後面要擦屁股的動作多了。我爲什麽一直說那些靠現成工具的人是學不到技能的，就是這個原因，他必然是一丁點小改動也應付不來，因爲他根本就不瞭解原來的怎麽來，現在要怎麽改，當然也不知道了。

[此贴子已经被作者于2015-11-7 12:48编辑过]