控制消息匹配的時候，竟然把memcmp寫成了memcpy
兩個函數的參數格式完全一樣，找了半天，甚至驚動了老大
交易列表的失敗
做資金拆借交易管理，按照老大的意思是，直接用new TXXXItem[Count]的方式，看原來其他遠期結售匯等交易的也是這樣，感覺挺失敗，怎麼說呢？交易列表是要實時更新的，這樣每天加一筆交易就要把內存刪除一次，然後從數據庫讀取一次，明顯的增加了負擔。如果用TList，直接在後面添加一筆不是挺好。
是挺好，可還是必須按照別人安排好的老路走，老路是他們的經驗走出來的，有什麼辦法。
6月25日 22:51 補：
再對這段業務深入瞭解一點，發現交易列表，其實是不需要保存在內存的，想來也是，如果是一般的櫃檯業務，一天做下來那業務量會有多大，更別說是服務器了，能受得了嗎？不過這裏做的都是總行和分行之間的交易，次數不會很多（數量可能就大得驚人了）。資金拆借業務初步理解是總行和分行之間的劃款，他們說的外匯買賣的平倉（分行的某外幣數量過多，向總行上交）在這裏不知道是否適用（上存？？）？以及分行之間的劃款，電子聯行吧！另外還有什麼人行XX的，就不知道是怎麼回事了。
現在的做法是，當客戶端需要刷新交易列表（直接在界面上刷新，不存到內存），就直接通過Midas(1)從數據服務器取數據，這樣做的好處是減少了業務服務器的負擔，這裏業務服務器和數據服務器不是同一個，壞處是增加了網絡的流量，同時增加了Oracle服務器的負擔。呵呵，只要我們的軟件沒有問題就好。權衡利弊，還是這種方法好一點。他們寫的代碼，還是有許多值得我學習的地方，只是剛剛進入這個環境，對許多業務流程都不清楚，理解起來比較困難。
一直都以爲自己編程能力還行，剛剛參加工作，做的第一個比較像樣的項目就碰釘子了。我的任務是寫牌價的採集模塊，雖然在公司有好長一段時間了，也接觸過牌價控制的模塊，但是都是修修補補的一些。按照公司原有的一個牌價採集程序來寫，寫出來實在太爛，太爛。不是我的問題，但是，我卻脫不了干係！
7月1日 15:46 補：
上面說到刷新交易列表的做法其實不是最終做法，優化的方法是，第一次刷新的時候通過Midas直接從數據庫刷新，後面，如果該窗口已經打開，當有新交易進來的時候，直接把新交易添加到交易列表的後面，不知道是不是自己不夠精明呢？總是在認識有誤以後再去糾正自己的錯誤認識，別人的認識是不是就能一次到位呢？認識總是在不斷深入的，這也是一個學習的過程。