近日用vc寫乙個gdi相關的程式時,一不小心栽了跟頭,害得我浪費了整整一天的時間來debug!!
跟頭1:colorref的high-order byte
我在處理的透明色是,用到了如下**:
colorref color1 = ....;
colorref color2 = ....;
if (color1 = = color2)
可是很奇怪的是,兩種顏色明明是一樣的,可if的判斷條件就是不滿足!!!最後發現是colorref的high-order byte 的問題. 我們知道rgb三色共占用了3個位元組,剩餘的1個位元組對顏色來說是無效的,但對 "==" 比較來說就有效了!!原來我的color1和color2的high-order byte不相同!!其實,按照msdn的說法,這個byte必須為0的,不過好像不為0也不影響gdi的繪圖,就是比較時出問題.
於是我寫了乙個巨集,no_high_byte_color
#define no_high_byte_color(clr) ((clr)&0x00ffffff) //取出沒有high-order byte 的colorref值(置high-order byte為0)
然後把判斷處該為:
if (no_high_byte_color(color1) = = no_high_byte_color(color2))
以防萬一. :)
跟頭2:{}和區域性變數
這個就比較弱智了.呵呵,純粹是自己粗心
我寫的乙個畫字串的函式(drawtext api的擴充套件,可以指定字型,背景顏色等,但是測試發現有連續執行幾百次後出現字型錯誤和花屏(win98下如此.但奇怪的是gid資源洩漏在xp下似乎沒有影響,容錯性好???......),根據經驗,很明顯就是資源洩漏了.經過排除,最後鎖定了下面這個成員函式,但怎麼看都看不出問題,最後還是同事"一語驚醒夢中人",幫我找出了錯誤.呵呵,錯在**?自己看**吧.注意紅色部分......
class ccanvas : public cdc
......
int ccanvas::drawstring(const cstring &str, lprect lprect, uint uformat, hfont hfont, colorref clrtext, bool bltrans, colorref clrbk)
int nresult = drawtext(str,lprect, uformat);
//set back
if (hfont)
settextcolor(clroldtextcolor);
setbkcolor(noldbkcolor);
setbkmode(noldbk);
return nresult;
}函式中任何地方都可以宣告變數是c++的乙個特性,確實很方便,但有時也會帶來隱患,當然,前提是你足夠粗心:)我個人認為,這樣的情況(內層作用域的變數和外層作用域的變數重名)編譯器是應該來個warning的,不知道這個是不是違背了"c的精神"所以才沒有做....呵呵,不僅懷念起pascal的var了......
給大家講兩個故事
那年盛夏 廣東的一所高校 教室裡，男生和女生 男生對女生有意，可是卻不知道女生的心思 唯唯諾諾 男生對女生說 hi，做我女朋友好嗎？女生 呃。女生不忍直接拒絕男生 這時她拿出手機 纖纖玉指輕盈地舞動 接著，她說 如果你能算出 27157793606596 的平方根 我就答應你 男生面露難色 這。能用...
解決了兩個sql問題
friday february 17,2006 05 24pm cst 1。decode 不僅僅針對固定值 case when b.aggregateno is null or b.aggregateno then customerid else b.aggregateno end 也可以寫成 de...
田志剛 寫文章的兩個好處
1 整理自己的思想，使之更加系統化，促進個人學習和成長 人與人的差距在起始的時候並不大，但一年 三年 五年 十年後差距就顯現出來了 可能在這十年中，大家做了同樣的事情，由於前者善於總結 反思 提煉，從而每做完乙個事情都能有所長進，能夠做到舉一反三，也就是所謂的 學而不思則罔 最後的結果是前者與後者的...