setwindowsubclass，然後return defsubclassproc(hwnd, umsg, wparam, lparam);，不要有ws_child這個 style。
翻 controlspy 的時候發現了bs_groupboxstyle，結合腦補覺得這是類似frame的東西，安排了乙個還真是。
controlspy 截圖，無 hidpi 支援
那麼既然控制項要放在 frame 裡，而 frame 是一種 button，那麼就會存在按鈕巢狀「按鈕」的情況發生，所以bs_pushbutton應該也是可以巢狀bs_pushbutton的，甚至可能可以巢狀static。
測試程式，開了 hidpi 支援，所以高畫質一些
然後測試事件繫結的時候就發現了問題，wndproc裡面沒有收到訊息，然後簡單翻了一下發現會傳wm_parentnotify，然後在wndproc的**裡面加上了這個case，的確收到了，但是根據文件來看這個東西給出的事件和資訊都很有限，甚至後期測文字框的時候文字框的change事件都收不到，所以就鍋++了。
當時查了挺多的東西，翻這些網頁流量都 300 多 m（寬頻），可見有多猛。。看了許多相關不相關的東西，啥 mfc 的、getmenu什麼的都有看過，雖然開的時候就知道這種東西不太相關但是還是看了看。
因為前一天太猛，第二天累到**，咕了一天。
首先是簡單整理了一下原來建textbox的**，然後依然是從wm_parentnotify開始找起，看到了wm_notify，然後了解了一下 windows 的訊息流程，隨著引導看到了sendasyncproc，但是對解決問題都沒啥用，又抱有一絲希望。花了一段時間去研究為啥收不到wm_notify，沒啥發現，最後也沒收得到，然後看到了 mfc 相關的一些東西，發現這麼方便，有一點酸，但是專案架構原因只能用原生。
最後，在這裡 child windows does not receive wm_destroy?，看到了真正的答案。既然涉及到了 child windows，要手動收到wm_destroy就說明題主想要在 destroy 時額外做點什麼，而如果能解決，就必定有遍歷發訊息什麼的。其實之前看到了乙個提問，只是下面沒回答。然後就說到了setwindowsubclass，順理成章地看文件，發現就是要的這個，然後放上去。
放上去之後 f5 開幕雷擊，整個視窗算是全白的，之前在新的**裡就是直接調的舊的**，然後折騰了一下試了幾種方案都不行，回去看**發現在構造的時候 or 了ws_child，然後既然setwindowsubclass了，就不像是乙個 child，注釋掉就好了。
用了這個以後之前註冊控制項類**掛掉，錯誤的註冊方法沒啥問題的註冊函式可以不用要了。
win32 單選按鈕
include 包含標頭檔案 匯入靜態庫 pragma comment lib,comctl32.lib 開啟視覺效果 copy from msdn pragma comment linker,manifestdependency type win32 name microsoft.windows....
win32 訊息機制
2 windows訊息系統組成 訊息佇列 作業系統負責為程序維護乙個訊息佇列，程式執行時不斷地從訊息佇列進行訊息的獲取，處理訊息 訊息迴圈 應用程式不斷地獲取訊息，處理訊息構成訊息迴圈。3 win32訊息路由 1.訊息產生 2.系統將訊息排列到其應該排放的執行緒的訊息佇列中。3.執行緒中的訊息迴圈呼...
win32 訊息機制
本次使用的開發環境是vs2013,使用的開發語言是c c 建立的專案是win32專案 當 windows 應用程式開始執行時，系統會為該程式建立乙個訊息 佇列用於存放訊息，然後用 getmessage 等進行訊息獲取處理。程式從佇列中獲取訊息後處理 分為系統訊息佇列 有系統維護,存放系統產生的訊息如...