re: GUI框架：消息檢查者 Richard Wei 2012-09-04 09:57
mark下
對于如何關聯HWND和CWnd常用有3種方法:
(1)MFC的Map,就是博主上面用的
(2)把CWnd指針放在CreateWindowEx的最后一個參數里，在回調WM_NCCREATE里從CREATESTRUCT里取出來，再保存CWnd*到SetWindowLong(GWL_USERDATA)中，后面其他消息就直接取出CWnd*調用
(3)ATL的Thunk機制
第一種方法容易理解，但是低效
第二種方法把CreateParams和UserData用掉了，別人沒法再用了，通用性不是很好
第三種方法簡單高效，但是會涉及到機器碼
支持一下,不過即使有D3D和WPF的經驗,做這個東西也不是容易的事
re: C++中實現回調機制的幾種方式 Richard Wei 2012-08-28 17:43
借助C++11種的function, 可以讓我們無差別的對待普通函數和類成員函數，實現delegate會容易很多
re: 關于PostMessage在多線程中的內存釋放問題 Richard Wei 2012-08-21 11:19
@Dragon
是的，你可以試下連續Post 100條Message，然后結束結束接收線程，所有的消息就都被丟掉了，自然就內存泄露了。
re: 共享個人寫的一個截屏小工具 Richard Wei 2012-08-21 10:56
@bukebushuo
可以截層窗口, 不過截硬件加速的視頻不行，那個需要用API Hook.
re: 關于PostMessage在多線程中的內存釋放問題 Richard Wei 2012-08-20 21:04
PostMessage只是把消息放到線程消息隊列，線程退出時并不保證隊列中的所有消息都已經被處理，所以博主上面的解決方案仍然會有內存泄露。
re: 如何學習WindDbg Richard Wei 2012-08-15 17:50
@zaccheo
VS2008 Release版默認編譯選項就是生成PDB符號的，在有符號的情況下用WinDbg調試程序其實不需要什么匯編知識。
re: 不知道能不能這里前輩交流一下（編程技術討論吧） Richard Wei 2012-08-15 14:21
博主不錯，比我畢業時厲害多了。
re: 如何判斷一個C++對象是否在堆上 Richard Wei 2012-08-13 14:30
上面關于對象是否在堆上的判斷應該是不對，因為堆內存不是連續內存，內部是通過類似鏈表的結構來實現的，<<軟件調試>>里有相關介紹，也可以通過WinDbg的 !address 命令查看內存分布
re: 堆棧楨的生成原理 Richard Wei 2012-07-20 15:31
據寫過調試器的朋友指點，調試器會盡量減少代碼運行時的干預，所以上面關于函數調用時調試器保存調用現場的猜測，應該是不正確的。
調試器更多的可能是根據PDB文件信息來計算推理的，如果沒有PDB文件，它就只能猜測，很多堆棧信息就會出錯了。
據說<<軟件調試>>里有相關介紹，回頭看下, 希望這篇博文不要誤導他人。
re: 開源一套DirectUI界面庫 Richard Wei 2012-07-20 08:36
@oksbsb
不知道你那邊為什么不行，我試了下還是可以下的， 代碼已發。
re: LingosHook : 值得紀念的一天 Richard Wei 2012-07-17 09:22
恭喜一下。
一直也想搞自己的軟件，無奈一直沒時間。
如果要用顯試調用類，建議還是用接口方式吧，導出一個CreateInstance(interface** ppInterface)就可以了，簡單又方便，具體參考COM
re: 開源一套DirectUI界面庫 Richard Wei 2012-07-16 19:43
@圣
資源壓縮和delegate方式的事件處理加上去也不難。
這套東西只是半成品，本來想寫給自己用的，可看了WPF后，覺得沒必要寫了，微軟已經把我們想做的東西做到了極致...
re: 跨模塊傳參數的教訓 Richard Wei 2012-07-16 10:04
@zuhd
恩,跨模塊返回一個未初始化的CString會有同樣的問題,
所以跨模塊還是用C語言的字符串方式比較保險。
re: 開源一套DirectUI界面庫 Richard Wei 2012-07-11 11:03
@先鋒
不用WTL，ATL就夠了。
相信這套東西會給真正研究過DirectUI的朋友很多參考價值。
re: 開源一套DirectUI界面庫 Richard Wei 2012-07-11 11:00
@圣
真想罵人，你看過代碼嗎？？ 別弄臟了這里。
re: 用Windbg解決一個Bug Richard Wei 2012-07-08 10:08
@weolar
是的, 理論上Vc和Windbg用的是相同的的調試引擎,但是我試了些VC的command,設置斷點的bp和察看堆棧的kv都不支持，不知道怎么回事。
另外windbg本身很小，在QA機器上安裝也很方便。
re: 如何減小Exe, DLL 的大小 Richard Wei 2012-07-07 15:23
感覺另外還有應該盡量少用全局和靜態變量，他們會被直接編譯到PE文件的數據(.data, .rdata)段中；另外圖片等資源也挺耗空間，簡單的圖片可以在運行時自己畫出來。
re: MUILIB題外話:Windows真的沒落了嗎 Richard Wei 2012-07-04 14:53
@萬連文
不扯了，我最初的本意只是提醒博主：他想靠現在的基于GDI的DirectUI賺錢會很難.
re: MUILIB題外話:Windows真的沒落了嗎 Richard Wei 2012-07-04 13:26
@萬連文
我也看好HTML5.
對于Native應用,我覺得正如Mac上的Cocoa，windows上趨勢則是WinRT和Xaml。
設計好的界面引擎的確應該和底層Rendering的方式無關，無論GDI，D2D(D3D)，或是OpenGL，但是3D和2D接口是如此不同以致現時中很難看到他們的統一。
說Windows沒落或許有點過了，但是windows上傳統桌面應用開發的減少現在卻是趨勢.
至于我那套界面，高手眼中的確是玩具程序，初學者或許可以拿來入門.
re: MUILIB題外話:Windows真的沒落了嗎 Richard Wei 2012-07-04 11:28
@bukebushuo
微軟不可能修改傳統GDI接口的內部實現來支持硬件加速, 因為修改沒那么容易，那樣也意味著所有老的基于GDI開發的應用程序都要做兼容性測試. 即使要增加支持硬件加速的接口,也會以新的方式提供(比如D2D)。這里最關鍵的是微軟有了自己的Xaml界面的標準， 外面的人這塊市場很難進入了。
我只是善意的提醒...
re: MUILIB題外話:Windows真的沒落了嗎 Richard Wei 2012-07-03 21:39
本不想回復了,想想還是回復下吧.
我感覺經過這么多年的發展，windows的桌面應用軟件已經開始飽和，所以windows上的新應用程序也越來越少，大部分是已有程序的維護和升級。當然作為主要的辦公平臺，在沒有找到新的辦公方式之前，windows傳統的桌面應用還將在一定時間內長期存在。
隨著XP的淡出，基于GDI/GDI+開發的界面也會逐步被支持硬件加速的D2D/D3D應用所取代，傳統的窗口控件機制也將逐漸退出，所以個人在這時基于GDI/GDI+開發DirectUI已經沒有多少意義。而微軟Xaml方式的界面（WPF, Metro )正逐步成為新的Windows界面標準，所以我相信微軟以后傳統桌面下也會有支持觸摸、支持自動測試的Native版本的WPF。
至于移動領域，我個人覺得微軟可能會通過WinRT實現PC, win8平板，windows Phone開發方式的統一。
很多開發人員(包括我)都不愿意放棄自己辛苦學習的已有技術，但是我不得不說GDI過時了...
re: MUILIB-可視化界面編輯器功能測試版完成 Richard Wei 2012-07-03 09:27
re: MUILIB-可視化界面編輯器功能測試版完成 Richard Wei 2012-07-02 19:14
如果想賺錢，windows傳統桌面下界面應用已經沒有多少前途，尤其是基于GDI的，希望不要在錯誤的道路上越走越遠； 當然如果是興趣，玩什么的都沒錯。
re: 關于編程的胡扯 Richard Wei 2012-06-22 09:37
不錯，正在為平臺而煩惱，支持一下
re: 遠程線程入門 Richard Wei 2012-06-20 23:53
@飯中淹
不依賴匯編重定位的代碼注入也做了下嘗試，發現挺好用的，測試代代碼也放上去了，單純用Ｃ＋＋就可以了，就是注入代碼大小不太好算。
re: 遠程線程入門 Richard Wei 2012-06-20 21:30
@飯中淹
是的，我們可以先在目標進程中把需要的數據分配好，然后通過線程參數把地址傳進去，這樣可以避免全局變量。
關于代碼注入，這篇文章不錯：
http://www.vckbase.com/index.php/wv/1580
re: 為什么設計模式在C++社區沒有Java社區流行? Richard Wei 2012-06-20 11:12
@畢達哥拉斯半圓
不錯， 新加了
(6)C++支持多種編程模型，包括面向過程，面向對象，基于對象，泛型編程等，設計模式主要是基于面向對象的，而Java只支持面向對象開發。
re: 從自己的角度來看人生路 Richard Wei 2012-06-20 10:22
博主還很年輕
re: 跨越Win8 Metro開發 Richard Wei 2012-06-15 16:56
@空明流轉
是的，微軟做了我們想做的，如果Desktop下也有Native的Xaml UI, 那么自己開發DirectUI就沒多少用處了。
re: 為什么設計模式在C++社區沒有Java社區流行? Richard Wei 2012-06-15 16:52
@leolai
是的，設計模式在比較大型的C++開源項目中用的還是比較多的，比如網絡庫ACE，界面庫QT，游戲引擎Orge, Irrlicht等
re: 跨越Win8 Metro開發 Richard Wei 2012-06-15 16:43
@leolai
恭喜你，看來Metro開發對你沒多少障礙
re: richedit研究02 – 大綱 Richard Wei 2012-06-15 09:48
關注, Win7下例子跑不起來
re: 為什么設計模式在C++社區沒有Java社區流行? Richard Wei 2012-06-15 09:24
@春秋十二月
恩，你長大了 :)
re: 難以割舍的二段構造 Richard Wei 2012-06-14 16:37
支持一下，C++里我們一般把分配內存和簡單的初始化工作都放在了構造函數里，而把一些復雜的工作放在一個單獨的初始化函數里，這樣的話比較靈活。如果覺得使用不方便，可以自己封裝一層，也就是所謂的RAII了。
re: 如何定義變長的TLV結構體？ Richard Wei 2012-06-14 16:23
windows API里很多結構體的第一個字段一般都是UINT cbSize， 就是為了以后可以擴充。
re: 為什么設計模式在C++社區沒有Java社區流行? Richard Wei 2012-06-14 11:16
@春秋十二月
看來你沒看懂, C or C++ :)
re: 軟命令接口的適用場合 Richard Wei 2012-06-13 21:08
@jacky
確實應該是facade, 只留意大概讀音，沒想到拼寫錯誤。
多謝指正。
re: Windows 8 基本概念 Richard Wei 2012-06-13 13:50
最近也開始關注Win8開發，無奈一直沒法入門，感覺從Desktop開發轉換到Metro開發的幾個門檻是:
(1)C++/CX語言本身的學習及語言背后的原理。
(2)Metro模式背后原理的學習，搞清楚它和傳統Desktop的交互和關系。
(3)WinRT類庫的學習， 最好對整個WinRT的體系結構進行系統的介紹。
(4)通過XAML開發UI的學習， 這個東西對很多WPF的程序員來說很容易，對其他人來說就沒有這么簡單了。
(5)D3D的學習，以及D3D和XAML UI交互的學習，開發一些高端產品最后還是需要在XAML里嵌入很多自己rendering的東西。
我覺得當上面的層次都掌握了，才可以說自己真正懂Metro開發了。 希望摟主可以按上面層次作些介紹。
re: 軟命令接口的適用場合 Richard Wei 2012-06-13 13:29
@華夏之火
這個怎么說呢，Faced模式強調的是一個復雜系統對外有一個統一的入口； Bridge模式強調的是分層的概念，將抽象層和實現層分離，二層可以分別獨立的變化。感覺上面的"軟命令"方式，從對外暴露的接口的簡單統一性來說比較符合Faced模式；但是從內部實現來說，你要理解成同一消息可以有多種處理方式，Bridge模式也可以。
re: 一道考驗你設計能力的C++編程題 Richard Wei 2012-06-13 13:06
@leolai
同意。
一般來說，除非某些設計模式你現在確實適合使用，或是你能預測到今后可能的變化，你才應該使用該模式。
否則還是只要滿足當前的需要就夠了，等確實有新需求時再考慮重構你現有的代碼。比如上面有的 去邊框(unframe), 用XML格式打印圖片的組成結構 等，都是新需求。
re: C++11新特性不完全測試 Richard Wei 2012-06-13 10:39
@華夏之火
恩，大家本來對concept期望很大， 如果真的有concept， C++11就完全是一門新語言了。
re: 敢問路在何方? 一個老程序員的真情告白！ Richard Wei 2012-06-12 22:09
佩服樓主，樓主還在杭州嗎，我也在杭州
re: 消息發送VS設計模式 C++沉思錄的一練習題的另解 Richard Wei 2012-06-12 20:26
這個例子源自《C++沉思錄》，同時也建議樓主看一下這本書，它會告訴你Why C++, how C++?
re: 消息發送VS設計模式 C++沉思錄的一練習題的另解 Richard Wei 2012-06-12 19:48
當然，看了樓主一些博文，我還是挺佩服樓主的，就是希望樓主不要癡迷于windows 消息處理函數的設計機制。
re: 消息發送VS設計模式 C++沉思錄的一練習題的另解 Richard Wei 2012-06-12 19:42
既然原文是指我的博文，我來嘗試評價下樓主上面的實現,如果有不正確的地方，請指正:
(1)樓主用C的方式來模擬C++的虛函數，除了以后難維護外，得到了什么好處?
(2)Windows用軟命令的方式來實現消息處理函數, 是因為消息類型太多，而且方便以后擴展新消息，我感覺用的恰到好處，但樓主這里也用這種方式就感覺有點過了。如果都按照這種方式，無論什么類都只要一個CommandHandler函數就夠了。我個人覺得一個用途明確的接口才是優雅的設計。
(3)請問樓主如何處理去邊框(unframe)的情況,如何知道當前的對象是不是支持unframe?
(4)樓主有沒有發現main函數里使用你的接口時特別別扭(比如這個代碼CHorseDecorater hors(pict1.m_Imp, pict2.m_Imp); pict1.Print(cout);), 我覺得良好的設計，應該讓使用的人覺得很舒服。
(5)樓主看起來挺討厭設計模式，但是在某些情況下用正確的設計模式確實可以讓你的程序有很好的可擴充性，畢竟它們是大師智慧的結晶。
re: 一道考驗你設計能力的C++編程題 Richard Wei 2012-06-12 11:12
@Simon
呵呵, 夸我還是罵我？