love in C++, live on MFC

鼠標(biāo)用久了，容易肩膀疼，所以有時(shí)候要換到左邊，然后需要的時(shí)候，再換到右邊。每次到控制面板里改還蠻煩的。

現(xiàn)在好了，自己寫了個(gè)程序，快速切換：當(dāng)前是右手習(xí)慣就換到左手習(xí)慣；反之換到右手習(xí)慣
程序很小，只有2行代碼：

參考了這篇blog：用C#實(shí)現(xiàn)鼠標(biāo)左右鍵自動切換

編譯后的程序下載

Dither這個(gè)詞怎么翻譯？我是指在window中的術(shù)語，常見的詞組solid color, ditherd color，見下圖

發(fā)布SnifferFox Beta版本了沒有看,但是源代碼也許可以研究下

初嘗結(jié)對編程的甜頭?是最XP編程的自己的理解.我現(xiàn)在比較喜歡看關(guān)于模式或者XP之類的熱門話題在軟件工業(yè)中實(shí)際的應(yīng)用和自己的理解 ,而不是對書的摘抄或者演示性的代碼.

Developers skills test ?eMule項(xiàng)目組的找人筆試題,看了下,發(fā)現(xiàn)自己還不能去eMule做開源項(xiàng)目啊,唉,

?C++ 完全不完全資源導(dǎo)引--書籍篇 后面的精力過剩類和打擊信心類的書都可以讀讀 :)

有兩個(gè)工程W.exe, 和c.dll
每次我從w調(diào)試c的時(shí)候都是可以直接從w工程設(shè)斷點(diǎn),調(diào)試進(jìn)入c源碼的.c的源碼我有,在另外一個(gè)目錄下.這是個(gè)我覺得很好的功能.
結(jié)果有一天,我拷了個(gè)新的c工程,編譯后,發(fā)現(xiàn)從w進(jìn)不了c代碼了,即使勉強(qiáng)進(jìn)去了,居然不是停在函數(shù)的第一句,而是在某個(gè)循環(huán)體內(nèi).
...
...
后來看了一下,原來,在w工程的debug目錄下,還有個(gè)c.lib和c.dll的老版本;而新版的c.lib和c.dll在w工程的根目錄下.而調(diào)試的時(shí)候,debug目錄下的dll lib是優(yōu)先的(猜測)
...
...
所以,只是個(gè)粗心的問題,不是技術(shù)問題.

如果看到這個(gè)標(biāo)題時(shí),還不知道什么是errno,那么,你就和我一樣.呵呵,我編程也有4,5年了,今天才知道errno.
errno不是我定義的一個(gè)變量,也不是否個(gè)隨意的變量名,而是crt庫中定義的一個(gè)全局變量
定義:errno Constants (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_errno_Constants.asp)
實(shí)際上,就是再一些crt函數(shù)調(diào)用后,errno會被賦值,表示函數(shù)調(diào)用的狀態(tài).有點(diǎn)類似window api中的GetLastError
這些crt函數(shù)包括fgetpos或者ftell和strtol之類.
在什么時(shí)候用它呢?看下面的一個(gè)例子:
這個(gè)時(shí)候,nValue = 0x7fffffff,你如果只是根據(jù)它來判斷,是不知道實(shí)際上已經(jīng)出錯(cuò)了.所以,這個(gè)時(shí)候必須借助errno來判斷狀態(tài).

慚愧啊,今天才知道.今天看strtol的msdn文檔,看到一句話For both functions, errno is set to ERANGE if overflow or underflow occurs.,我看了半天沒有找到errno,后來一搜,才發(fā)現(xiàn)它居然是個(gè)全局變量.

中文不是很好翻譯,可以理解成"不論真假；隨便說說"
常用句型:
FWIW, I think poster means...
poster這里是樓主的意思,呵呵

今天突然想起一個(gè)問題，在mfc里面，比較典型的程序模型，dialog， sdi，mdi。特別的，有doc/view結(jié)構(gòu)。有點(diǎn)類似于mvc結(jié)構(gòu)，影響了一代又一代mfc程序員。
那么mfc8.1中，能不能多些這樣的結(jié)構(gòu)吧？把當(dāng)前比較流行的設(shè)計(jì)模式，都做成現(xiàn)成的類，放在mfc中

呵呵，那個(gè)時(shí)候，我估計(jì)沒有人再說mfc設(shè)計(jì)的很爛了吧？

不過很奇怪,開源社區(qū)那么多人在用java c#討論設(shè)計(jì)模式,MFC領(lǐng)域的卻很少,真是奇怪

鋒鋒說：
把代碼投影在墻上，幾個(gè)人坐下來一起評論也是有效的方法

呵呵，我覺得很cool啊，可惜現(xiàn)在我不是老板，等我哪天成老板了，就這么做

windows窗口系統(tǒng)的3個(gè)分層

z－order的初始順序就是窗口創(chuàng)建的先后順序

對于子窗口，z-order于tab 順序的關(guān)系

書上說匈牙利命名法已經(jīng)過時(shí)了，我不這樣認(rèn)為。

有人認(rèn)為現(xiàn)在編譯器已經(jīng)可以很好的檢測出類型的不匹配，或者IDE中可以很快的看到類型，所以在c中可能需要，在C＋＋（強(qiáng)類型語言）中就不需要了。
C++ made it harder to do that without wicked casting and the compiler catches most of those kind of errors.? So, I agree with the previous poster that it's now redundant.
Also, modern IDEs allow you to hover the cursor over a variable and show you the variable's definition.

不過我覺得代碼不是寫給編譯器看的，而是寫給人看的，這里就有self-documenting和readability的問題。
很明顯，如果你看到nIndex 或者strFile或者wndNext，就可以很快知道分別是int CString CWnd類型，而不用回頭去看變量定義，這樣，看代碼時(shí)就會很快。
而且，對于MFC程序員來說，更重要一些，因?yàn)镸FC里面的變量都是用匈牙利命名法的。
If you're programming C++/MFC you're better sticking to hungarian for consistency with the class library & Win32 API declarations.
微軟的約定，就是標(biāo)準(zhǔn)了

不過，書上提到在泛型編程中不需要，現(xiàn)在體會還不深，可能是對的。

今天(2006 04 13碰巧看到codeproject的一個(gè)vote),結(jié)果如下

Option	Votes	%
Pascal Cased	171	10.6
camel Cased	702	43.4
Fixed letter prefix (eg lLocal)	81	5.0
Hungarian prefix (eg strLocal)	481	29.7
Scope prefix (eg l_Local)	36	2.2
Scope and Hungarian prefix (eg l_strLocal)	125	7.7
Responses	1618	?

Hungarian Notation排第二.
cp上面有兩個(gè)鏈接
Conversations: Hungarian wartHogs (http://www.cuj.com/documents/s=7989/cujcexp1911hyslop/hyslop.htm)
號稱這篇文章就已經(jīng)明白的說HN過時(shí)了(作者也是c++ coding stardard的作者).
如果不用HN,那么應(yīng)該用什么樣的命名規(guī)則呢?
Naming Guidelines(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconNamingGuidelines.asp)
.Net下的推薦,也許別的地方也可以用.