• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            我們知道Windows的窗口消息處理函數(shù)是C方式, 面向過程的, 所以窗口框架的基本任務(wù)就是將它轉(zhuǎn)成面向?qū)ο蟮姆绞剑?確切的說如何將消息處理函數(shù)第一參數(shù)HWND轉(zhuǎn)成對(duì)象指針。

            關(guān)于這個(gè)問題, 其實(shí)網(wǎng)上大家已經(jīng)說濫了,  這里只是簡(jiǎn)單記錄一下。

            Map方式:MFC就是采用這種方式, 就是建立一張從HWND到CWindow*的映射表, 每次收到消息都從Map中根據(jù)HWND找到CWindow*, 再進(jìn)行調(diào)用

            UserData的方式:CreateWindow時(shí)將最后一個(gè)附加數(shù)據(jù)設(shè)置為對(duì)象CWindow* 指針, 當(dāng)收到第一個(gè)消息WM_NCCREATE時(shí), 取出傳過來的附加數(shù)據(jù)指針, 將該指針設(shè)置成窗口的UserData,  SetWindowLongPtr(hWnd, GWLP_USERDATA, reinterpret_cast(pThis)), 后面收到任何消息就可以直接調(diào)用GetWindowLongPtr(hWnd, GWLP_USERDATA)取出窗口指針, 進(jìn)行面向?qū)ο蠓绞降恼{(diào)用。

            Thunk方式:這是ATL采用的方式,通過匯編代碼,直接將窗口消息處理函數(shù)的第一個(gè)參數(shù)HWND改寫成CWindow*, 然后進(jìn)行面向?qū)ο蠓绞降恼{(diào)用, 原理可以見我以前寫的 理解ATL中的一些匯編代碼

            這里也有一篇文章總結(jié)了這些封裝方式: MFC、ATL窗口消息封裝機(jī)制對(duì)比分析

            最近工作中要寫一些簡(jiǎn)單窗口相關(guān)的代碼, 考慮用什么方式封裝窗口過程:
            MFC肯定不引入, map方式也不考慮。
            UserData方式太低效 ,而且窗口的UserData讓框架用了,我們其他地方可能還要用呢。
            ATL的Thunk方式不錯(cuò), 但是我們不想引入COM, 也不想用ATL的庫(kù)和代碼。
            原始的 C API方式, 依賴性和效率都最佳, 可惜就是不是面向?qū)ο蟮摹?br />
            各有優(yōu)缺,怎樣才能熊掌和魚翅兼得?

            最后決定把ATL中窗口Thunk相關(guān)的核心代碼剝離出來, 做一個(gè)完全獨(dú)立的最基本窗口框架。我們框架的基本目標(biāo)是可以讓我們方便的開發(fā)一些簡(jiǎn)單的窗口, 所以去掉了ATL窗口中一些不常用或是可替代的東西, 只留下必須和最有用的。簡(jiǎn)單說來,把ATL中的CWindow給去掉了,它只是窗口API的封裝, 我們可以直接調(diào)用API來實(shí)現(xiàn);把CWinTraits給去掉了,因?yàn)樗皇谴翱陲L(fēng)格的封裝; 把SubClass和SuperClass也去掉了, 我們的簡(jiǎn)單窗口用不到這個(gè)特性; 把Dialog, Container和COM相關(guān)的都去掉了, 這些都不是窗口的核心部分。最后只留下,窗口注冊(cè)創(chuàng)建, thunk和消息映射相關(guān)的代碼。

            測(cè)試了下,這個(gè)窗口框架基本上只有2個(gè)核心文件,完全獨(dú)立, 可以直接放到任何現(xiàn)有框架中使用(ATL/WTL中使用可能要改下內(nèi)部一些類名, 但是用了ATL/WTL肯定就不用這個(gè)框架了)。

            測(cè)試代碼: CAltWinTest.rar
            posted on 2013-09-08 14:47 Richard Wei 閱讀(4405) 評(píng)論(11)  編輯 收藏 引用 所屬分類: windows desktop

            FeedBack:
            # re: 關(guān)于Windows窗口框架[未登錄]
            2013-09-08 17:46 | avlee
            做一個(gè)最基本窗口框架,可以完全不要使用消息映射,也就可以不需要使用thunk了。  回復(fù)  更多評(píng)論
              
            # re: 關(guān)于Windows窗口框架
            2013-09-08 19:16 | Richard Wei
            @avlee
            嗯,關(guān)鍵我們希望是面向?qū)ο蟮模?方便的支持多實(shí)例, 并且希望是線程安全的,這個(gè)框架都很好的滿足了。消息處理是窗口程序的根本, 所以簡(jiǎn)單方便的消息映射也很重要。  回復(fù)  更多評(píng)論
              
            # re: 關(guān)于Windows窗口框架
            2013-09-08 22:27 | jilei
            也可以用 SetProp 吧  回復(fù)  更多評(píng)論
              
            # re: 關(guān)于Windows窗口框架
            2013-09-09 08:52 | Richard Wei
            @jilei
            不錯(cuò), UserData方式也可以用SetProp存儲(chǔ), 但是低效同樣也是它的缺點(diǎn)。  回復(fù)  更多評(píng)論
              
            # re: 關(guān)于Windows窗口框架
            2013-09-09 14:52 | 聶晏冰
            UserData方式太低效 只需要取一次,何來低效之說? 求解  回復(fù)  更多評(píng)論
              
            # re: 關(guān)于Windows窗口框架
            2013-09-09 18:34 | Richard Wei
            @聶晏冰

            怎么取一次?
            每次收到消息都要轉(zhuǎn)的, 大概代碼如下:
            LRESULT CALLBACK XWindow::WndProc(HWND hWnd, UINT uMsg,
            WPARAM wParam, LPARAM lParam)
            {
            XWindow* pThis = NULL;
            if (WM_NCCREATE == uMsg)
            {
            assert(!::IsBadReadPtr((void*)lParam, sizeof(CREATESTRUCT)));
            LPCREATESTRUCT lpcs = reinterpret_cast(lParam);
            pThis = static_cast(lpcs->lpCreateParams);
            pThis->m_hWnd = hWnd;

            assert(!::IsBadReadPtr(pThis, sizeof(XWindow)));
            ::SetWindowLongPtr(hWnd, GWLP_USERDATA, reinterpret_cast(pThis));
            }
            else
            pThis = reinterpret_cast(::GetWindowLongPtr(hWnd, GWLP_USERDATA));

            if (pThis)
            return pThis->MsgProc(hWnd, uMsg, wParam, lParam);
            else
            return DefWindowProc(hWnd, uMsg, wParam, lParam);
            }  回復(fù)  更多評(píng)論
              
            # re: 關(guān)于Windows窗口框架
            2013-09-24 21:34 | 多多
            現(xiàn)在很多界面框架采用DirectUI的方式,一個(gè)窗口中的所有控件都由自己繪制,而不是像使用API那樣每個(gè)控件都對(duì)應(yīng)一個(gè)窗口類,簡(jiǎn)單的說就是一個(gè)窗口和它內(nèi)嵌的所有控件都只屬于一個(gè)窗口類,對(duì)應(yīng)一個(gè)HWND。窗口和控件的消息不依賴于API,完全由自己定義。

            優(yōu)點(diǎn)是靈活性非常大,窗口和控件的風(fēng)格完全由自己決定,不受限于系統(tǒng)風(fēng)格。
            框架接口完全不依賴于系統(tǒng)API,使用者完全不用關(guān)系系統(tǒng)的事件和消息,只需要使用你提供的事件和消息就行。
            缺點(diǎn)是工作量較大,每個(gè)控件都要自己重寫,每個(gè)控件的事件和消息都要重新考慮。

            QQ就是用的這種方式,另外很流行的界面框架Qt也是用的這種方式。  回復(fù)  更多評(píng)論
              
            # re: 關(guān)于Windows窗口框架
            2015-07-02 21:06 |
            @多多 自己決定風(fēng)格跟是不是directui沒啥關(guān)系。
              回復(fù)  更多評(píng)論
              
            # re: 關(guān)于Windows窗口框架
            2015-07-02 21:11 | 多多
            @龍 你沒看懂我在說什么。  回復(fù)  更多評(píng)論
              
            # re: 關(guān)于Windows窗口框架
            2015-08-07 13:10 | 溪流
            @多多
            大概是你沒看懂他在說什么吧  回復(fù)  更多評(píng)論
              
            # re: 關(guān)于Windows窗口框架
            2015-08-14 11:56 | 多多
            @溪流
            我是說用directui可以決定自己的風(fēng)格,不是說決定自己的風(fēng)格要用directui。這下懂了沒?

            也是強(qiáng)行秀自己語(yǔ)文……  回復(fù)  更多評(píng)論
              
            久久精品人人做人人爽电影| 国产精品久久久久久搜索| 久久天天躁狠狠躁夜夜不卡| 久久久黄片| 久久久久久久久久久久中文字幕 | 亚洲?V乱码久久精品蜜桃 | 中文字幕久久欲求不满| 精品多毛少妇人妻AV免费久久| 色婷婷综合久久久久中文字幕| 亚洲中文字幕无码久久2017 | 中文字幕久久亚洲一区| 久久亚洲精品中文字幕| 国产精品免费久久| 精品久久久久中文字幕日本| 久久久久久亚洲精品不卡 | 久久久久亚洲AV综合波多野结衣| 国产亚洲精久久久久久无码77777| 国产成人AV综合久久| 人人妻久久人人澡人人爽人人精品 | 久久久久久精品久久久久| 久久99热国产这有精品| 久久精品人人做人人爽电影 | 国产福利电影一区二区三区,免费久久久久久久精 | 亚洲日本va午夜中文字幕久久| 国产69精品久久久久777| 欧美成人免费观看久久| 久久精品国产亚洲av瑜伽| 久久99免费视频| 国产精品99精品久久免费| 久久久久久久久66精品片| 久久久久99精品成人片三人毛片 | 久久中文字幕精品| 久久精品国产清自在天天线| 99久久精品国产一区二区三区| 久久亚洲AV成人出白浆无码国产| 九九精品久久久久久噜噜| 午夜精品久久久久久影视777| 四虎国产精品成人免费久久| 久久激情亚洲精品无码?V| 久久国产精品一区| 亚洲欧美成人久久综合中文网|