• <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>

            cexer

            cexer
            posts - 12, comments - 334, trackbacks - 0, articles - 0
              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

            自己寫的一個GUI框架的消息機制

            Posted on 2008-08-06 17:54 cexer 閱讀(6991) 評論(39)  編輯 收藏 引用 所屬分類: GUI

            轉(zhuǎn)帖請注明出處 http://www.shnenglu.com/cexer/archive/2008/08/06/58169.html

              我看過一些開源 GUI 框架的源代碼,包括聲句顯赫的 WTL,win32gui 和 SmartWin,還有一些不知名但很優(yōu)秀的,包括 jlib2( java AWT 在 C++ 上的移植  ),F(xiàn)LTK (比較小跨平臺),甚至還曾鼓起勇氣去看過 QT 那 n 萬行的代碼(當然沒看明白)。

              其中我個人覺得最好的并不是 win32gui 或者 SmartWin,WTL 這些“名”庫,而是那個名不見經(jīng)傳的 AWT c++ 移植版本的 jlib2--AWT 的設(shè)計相當?shù)貎?yōu)雅。SmartWin 則多少有點名不附實,里面的尖括號(模板)多到讓人難以忍受的程度,實際上很多是不需要的,我在自己的框架當中只用了少量的模板就完成了 SmartWin 要完成的一部分功能。win32gui 是標準庫風格的代碼風格,看起來舒服,可是那接口也太古怪。

              我想 SmartWin 和 win32gui,WTL 這些庫那么出名,更多地是因為它們將一些非常有創(chuàng)意的手法運用到了 GUI 框架當中,想必以后的 GUI 框架都會多少受其影響。

              看這些庫都是為了“師夷長技“,因為我自己非常喜歡寫 GUI 框架,沒完沒了反反復(fù)復(fù)地寫。

              CPPBLOG 上關(guān)于 GUI 框架的東西不是很多,自己寫框架的少之又少。GUI 框架是如此大而復(fù)雜的一個車輪,除了少數(shù)像我這樣的偏執(zhí)狂,誰會愿意累得七竅流血去制作一個可能一開動就會車毀人亡的車輪呢?  

              寫大一些的框架,是一種鍛煉同時也是挑戰(zhàn)。GUI 框架更是如此,要寫一個好的 GUI 框架,就必須深入到很多的領(lǐng)域 ,比如線程,內(nèi)存管理,內(nèi)核對象,圖形處理等等,這些都是在程序設(shè)計當中不容易駕馭的東西,如果還要完成諸如 序列化,腳本接口 這些東西,GUI 框架涉及的領(lǐng)域可以說非常地深廣了。在與這些東西打交道的過程當中,我覺得自己慢慢地成長了不少。

              不過寫了數(shù)個版本,從來沒有自己覺得滿意的,想起以前的一個很牛的朋友說過:如果一個人看到自己很久以前寫的代碼仍然覺得滿意,那么這個人要么很牛,要么很蹉,不過可以想像,大多有這樣感覺的人都屬于很蹉的那一部分,可見自己覺得不滿意并不是壞事。一直寫,就能一直進步,總有一天會以牛人的身分回頭看看自己的代碼,而仍能覺得很滿意。

              我寫日志的一大問題就是,每次都是廢話說完一大堆,仍不知道怎么自然地進入正題,這一次讓我要以強硬的態(tài)度開門見山地進入。

             

            進入正題:

              介紹一下自己在寫的一個 GUI 框架。

              這個框架是以前幾個版本的進化版,它的消息處理機制比較有意思。下面是這個框架的消息映射部分的一個測試代碼,從這個代碼里可以看出來這個框架在消息處理上的一些創(chuàng)新。

               1: // cexer
               2: #include "../../cexer/include/GUI/GUI.h"
               3: #include "../../cexer/include/GUI/window.h"
               4: #include "../../cexer/include/GUI/message.h"
               5:  
               6: using namespace cexer;
               7: using namespace cexer::gui;
               8:  
               9: // cexer LIB
              10: #include "../cexerLIB.h"
              11:  
              12: // c++ std
              13: #include <iostream>
              14: using namespace std;
              15:  
              16:  
              17: class TestWindow:public Window
              18: {
              19:     CEXER_GUI_CLASS( TestWindow,Window );
              20:  
              21: public:
              22:  
              23:     TestWindow( ParentWidget* parent=NULL,LPCTSTR name=_T("") )
              24:         :Window( parent,name )
              25:     {
              26:  
              27:     }
              28:  
              29:     LRESULT onMessage( WidgetMessage<WM_DESTROY>& message )
              30:     {
              31:         ::PostQuitMessage(0);
              32:         wcout<<L"window destroyed"<<endl;
              33:         return message.handled(this);
              34:     }
              35:  
              36:     LRESULT onMessage( WidgetMessage<WM_CREATE>& message )
              37:     {
              38:         wcout<<L"window created"<<endl;
              39:         return message.handled(this);
              40:     }
              41:  
              42:     LRESULT onMessage( WidgetMessage<WM_SIZE>& message )
              43:     {
              44:         long clientWidth  = message.cx;
              45:         long clientHeight = message.cy;
              46:  
              47:         wcout<<L"window sized"<<endl;
              48:         wcout<<L"client width  is: "<<clientWidth<<endl;
              49:         wcout<<L"client height is: "<<clientHeight<<endl;
              50:  
              51:         return message.handled(this);
              52:     }
              53:  
              54:     LRESULT onCommand( SystemCommand<SC_CLOSE>& command )
              55:     {
              56:         wcout<<L"system command SC_CLOSE"<<endl;
              57:         return command.handled(this,0,false);
              58:     }
              59:  
              60:     LRESULT onCommand( SystemCommand<SC_MAXIMIZE>& command )
              61:     {
              62:         wcout<<L"system command SC_MAXMIZE"<<endl;
              63:         return command.handled(this);
              64:     }
              65: };
              66:  
              67:  
              68: int _tmain( int argc,TCHAR** argv )
              69: {
              70:     CEXER_GUI_THREAD();
              71:  
              72:     wcout.imbue( std::locale("") );
              73:  
              74:     TestWindow* window = new TestWindow();
              75:     if ( !window->create() )
              76:     {
              77:         wcout<<L"window creating failed"<<endl;
              78:         delete window;
              79:     }
              80:  
              81:     TestWindow child( window,_T("child") );
              82:     child.create();
              83:  
              84:  
              85:     return runGUIthread();
              86: }


            消息自動映射

              不像 MFC,ATL 那樣的 BEGIN_MESSAGE_MAP ,MESSAGE_HANDLER 之類的一大堆宏來湊成一個巨大函數(shù),也沒有像 QT 那樣的 connect(xxxx,xxxx) 的顯示連接信號和槽的代碼,你在上面的測試代碼里找不到任何的映射痕跡,但是它的確工作得非常好。在這個 GUI 框架當中,你只需要定義消息處理函數(shù),框架就能自動地幫你映射。例如上面定義的函數(shù):

               1: LRESULT onMessage( WidgetMessage<WM_DESTROY>& message )
               2: {
               3:     ::PostQuitMessage(0);
               4:     wcout<<L"window destroyed"<<endl;
               5:     return message.handled(this);
               6: }


              框架在遇到 WM_DESTROY 消息的時候,會自動地調(diào)用這個函數(shù)。

              框架當中的 WidgetMessageBase 和 WidgetCommandBase ,SystemCommandBase 等模板以基類的形式,給派生類提供消息自動映射的能力。WidgetMessage,WidgetCommand,SystemCommand 等模板則提供了所有消息的一般實現(xiàn)。利用這些模板,只需要很簡單的步驟即能完成消息映射和處理。

              比如說要實現(xiàn)對消息 WM_CREATE 的處理,只需定義一個函數(shù):

               1: LRESULT onMessage( WidgetMessage<WM_CREATE>& message )
               2: {
               3:     // do something
               4:     // ...
               5:  
               6:     return message.handled(this);
               7: }

              
              要實現(xiàn)對 ID 為 IDOK 的按鈕的點擊事件的處理,只需定義一個函數(shù):

               1: LRESULT onCommand( WidgetCommand<IDOK,BN_CLICKED>& okClicked )
               2: {
               3:     // do something here
               4:     // ...
               5:  
               6:     return clicked.handled(this);
               7: }


              要實現(xiàn)系統(tǒng)菜單的關(guān)閉命令的處理,只需要定義一個函數(shù):

               1: LRESULT onCommand( SystemCommand<SC_CLOSE>& command )
               2: {
               3:    // do something 
               4:     // ...  
               5:  
               6:     return command.handled(this);
               7: }


              對于命令消息( WM_COMMAND),可以進一步地利用派生進行命令消息的分類處理,例如可以定義一個針對所有按鈕點擊事件的消息模板:

               1: template<UINT t_id>
               2: struct ButtonClicked:public WidgetCommandBase<ButtonClicked<t_id,BN_CLICKED>,t_id,BN_CLICKED>
               3: {
               4:     Button* button;
               5:  
               6:     template<typename TWidget>
               7:     ButtonClicked( TWidget* widget,UINT mess,WPARAM wpar,LPARAM lpar )
               8:         :_BaseCommand( mess,wpar,lpar )
               9:         ,button( widget->child(reinterpret_cast<HWND>(lpar)) )
              10:     {
              11:  
              12:     }
              13: };


              用這個模板同樣可以完成上面那個 ID 為 IDOK 的按鈕的點擊事件的處理,并且進一步地從消息當中分解出了按鈕對象的指針:

               1: LRESULT onCommand( ButtonClicked<IDOK>& okClicked )
               2: {
               3:     Button* button = okClicked.button;
               4:  
               5:     // do something 
               6:     // ...
               7:  
               8:     return okClicked.handled(this);
               9: }


              這些消息函數(shù)的名字并不是一定得命名為 onMessage 和 onCommand。它們可以是任何合法的 C++ 函數(shù)名。例如還是那個按鈕點擊事件的處理函數(shù)可以寫成:

               1: LRESULT buttonClicked( ButtonClicked<IDOK>& okClicked )
               2: {
               3:     Button* button = okClicked.button;
               4:  
               5:     // do something 
               6:     // ...
               7:  
               8:     return okClicked.handledBy(this,&Self::buttonClicked);
               9: }


            消息的手動映射:

              在有的環(huán)境當中(例如以 XML 為模板運行過程當中的某個時刻動態(tài)創(chuàng)建界面),控件是動態(tài)創(chuàng)建的,顯然這時候動態(tài)生成的控件 ID 不是一個編譯期常數(shù),因為這樣的 ID 不能用于模板參數(shù),所以無法使用消息的自動映射(自動映射需要控件的 ID 作為模板參數(shù)),這種情況下框架必須要提供手動映射的接口。

              這個框架同時對控件的命令消息(WM_COMMAND)和通知消息(WM_NOTIFY )提供了手動映射的接口。例如對按鈕提供了 onClicked,onDoubleClicked,對編輯框提供了 onChange,onUpdate 等這些用于消息映射的函數(shù)對象,客戶通過調(diào)用這些函數(shù)對象來實現(xiàn)手動映射(像onClicked 的這種函數(shù)對象其實本身并不處理消息,只是執(zhí)行一次消息映射的動作)

              例如要處理名為 button1 和 button2  的按鈕的點擊事件:

               1: int buttonClicked( Button* button )
               2: {
               3:     // do something 
               4:     // ...
               5:  
               6:     return 0;
               7: }
               8:  
               9: LRESULT onMessage( WidgetMessage<WM_CREATE>& message )
              10: {
              11:     buttonChild("button1")->onClicked( this,&Self::buttonClicked );
              12:     buttonChild("button2")->onClicked( this,&Self::buttonClicked );
              13:  
              14:     return message.handled(this);
              15: }


              手動映射對消息處理函數(shù)的類型要求比較寬松,例如上面的函數(shù) buttonClicked 的參數(shù)不局限為 Button* ,也可以是 Widget* 或 MessageListener*,或其派生路徑上任何一種類型的指針。返回值則可以為任何類型。


            消息參數(shù)分解

              這個框架除了消息自動映射,還能夠很輕松地針對不同消息分解出消息攜帶的信息。例如上面的函數(shù)當中:

               1: LRESULT onMessage( WidgetMessage<WM_SIZE>& message )
               2: {
               3:     long clientWidth  = message.cx;
               4:     long clientHeight = message.cy;
               5:  
               6:     wcout<<L"window sized"<<endl;
               7:     wcout<<L"client width  is: "<<clientWidth<<endl;
               8:     wcout<<L"client height is: "<<clientHeight<<endl;
               9:  
              10:     return message.handled(this);
              11: }


              針對 WM_SIZE 消息進行了消息的分解,因此在消息處理函數(shù)當中,不用再為了獲得 WM_SIZE 攜帶的信息(客戶區(qū)的寬度和高度)而一遍一遍地寫 LOWORD 和 HIOWRD ,而是直接就能從 WM_SIZE 消息參數(shù)的丙個成員當中獲取到它們:

               1: WidgetMessage<WM_SIZE>::cx 
               2: WidgetMessage<WM_SIZE>::cy 

              有兩種方法可以針對不同的消息以不同的方式分解參數(shù),一個模板的特化。在這個例子當中,WidgetMessage<WM_SIZE> 實際上就是是對模板 WidgetMessage<UINT t_message> 的特化

              WidgetMessage<UINT t_message>模板的定義如下:

               1: template<UINT t_mess>
               2: class WidgetMessage:public WidgetMessageBase<WidgetMessage<t_mess>,t_mess>
               3: {
               4: public:
               5:     WidgetMessage( UINT mess,WPARAM wpar,LPARAM lpar )
               6:         :_BaseMessage(mess,wpar,lpar)
               7:     {
               8:  
               9:     }
              10: };


              其中的 WidgetMessageBase 模板是一個提供消息自動映射的基類,所有需要自動映射的消息均從此模板派生,并且WidgetMessageBase 保存了三個未經(jīng)加工的原始參數(shù):

               1:   UINT      message
               2:   WPARAM    wparam
               3:   LPARAM    lparam


              因此所有的 WidgetMessage 模板的非特化版本所攜帶的參數(shù)都是這樣三個參數(shù)。可以通過特化的方式來從這三個參數(shù)當中進一步分解出想要的部分,測試代碼當中針對 WM_SIZE 來進行特化的代碼如下:

               1: template<>
               2: class WidgetMessage<WM_SIZE>:public WidgetMessageBase<WidgetMessage<WM_SIZE>,WM_SIZE>
               3: {
               4: public:
               5:     long cx;
               6:     long cy;
               7:  
               8:     template<typename TWidget>
               9:     WidgetMessage( TWidget* widget,UINT mess,WPARAM wpar,LPARAM lpar )
              10:         :_BaseMessage( mess,wpar,lpar )
              11:         ,cx( LOWORD(lpar) )
              12:         ,cy( HIWORD(lpar) )
              13:     {
              14:  
              15:     }
              16: };


              再舉例針對 WM_PAINT 消息利用特化來分解參數(shù):

               1: template<>
               2: class WidgetMessage<WM_PAINT>:public WidgetMessageBase<WidgetMessage<WM_PAINT>,WM_PAINT>
               3: {
               4: public:
               5:     Widget*     widget;
               6:     Canvas      canvas;
               7:     PAINTSTRUCT paintStruct;
               8:  
               9:     template<typename TWidget>
              10:     WidgetMessage( TWidget* w,UINT mess,WPARAM wpar,LPARAM lpar )
              11:         :_BaseMessage( mess,wpar,lpar )
              12:         ,widget(w)
              13:         ,canvas( ::BeginPaint(w->handle(),&paintStruct) )
              14:     {
              15:  
              16:     }
              17:  
              18:     ~WidgetMessage()
              19:     {
              20:         ::EndPaint(widget->handle(),&paintStruct);
              21:     }
              22: };


              這樣就從 WM_PAINT 當中分解出了需要的參數(shù)。然后在消息處理函數(shù)當中可以這樣使用:

               1: LRESULT onMessage( WidgetMessage<WM_PAINT>& message )
               2: {
               3:     message.canvas.drawText(100,100,_T("hello world"));
               4:  
               5:     return message.handled(this);
               6: }


              雖然看起來特化模板很麻煩,但是實際上這是“do it for once,use for ever“(麻煩一次,方便永遠)的事。

              還有一個分解參數(shù)的方法,就是直接從模板 WidgetMessageBase 派生。比如利用派生的方式分解 WM_CREATE 的參數(shù):

               1: struct WindowCreating:public WidgetMessageBase<WindowCreating,WM_CREATE>
               2: {
               3:     CREATESTRUCT* createStruct;
               4:  
               5:     WindowCreating( UINT m,WPARAM w,LPARAM l)
               6:         :_BaseMessage(m,w,l)
               7:         ,createStruct( reinterpret_cast<CREATESTRUCT*>(l) )
               8:     {
               9:  
              10:     }
              11: };


              現(xiàn)在 WM_CREATE 消息處理函數(shù)的樣子是這樣:

               1: LRESULT onMessage( WindowCreating& message )
               2: {
               3:     CREATESTRUCT* createStruct = message.createStruct;
               4:  
               5:     return message.handled(this);
               6: }


            總結(jié):

              世上沒有完美的東西,自己寫的東西在剛完成它的時候總覺得已經(jīng)完美沒有再優(yōu)化的可能了,但是每一次回頭再看,都會發(fā)現(xiàn)許多的不足。這個框架提供的消息處理機制很靈活和方便了,不過等過幾天再來看它,一定會發(fā)現(xiàn)能改進的地方。

            Feedback

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-06 22:52 by 陳梓瀚(vczh)
            原來你是這么做的。我花了很大的功夫,把delphi的方法搬到了C++里面,不惜成本讓『使用』方便。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-06 22:53 by 陳梓瀚(vczh)
            當然其中一個目標就是可以在也不管消息。你的方法在工程上是很好的,不過用起來還是會囧的。譬如將你的方法用在ListView上的時候。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-06 23:04 by Sil
            很不錯啊,非常期待博主放出全部框架。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-06 23:15 by cexer
            @陳梓瀚(vczh)
            不知道你說的很囧具體是什么?這個框架的上一個版本封裝了許多的控件,不過沒有封裝 ListView,所以不知道是否存在你說的問題,因為是實驗性質(zhì)的東西,還沒有在大的工程上測試過。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-06 23:20 by cexer
            @Sil
            謝謝支持,不過還在寫作當中。

            # re: 自己寫的一個GUI框架的消息機制[未登錄]  回復(fù)  更多評論   

            2008-08-06 23:43 by eXile
            最成熟的 GUI 庫當然是Qt, 你的設(shè)計還不錯,不過感覺還是native win32 的思維方式,沒有呈現(xiàn)出更高介的抽象,

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-07 08:44 by Strive
            以前就見他們寫GUI,一直沒欣賞到代碼,現(xiàn)在好了,有人給出做法了。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-07 09:17 by Kevin Lynx
            @eXile
            我亦覺得,樓主局限于native win32的思維方式。在對消息的處理上,遵從的是WIN32的消息機制。

            不過從代碼看來(LRESULT之類),這個框架可能沒有考慮跨平臺特性。所以停留在WINDOWS上也沒什么。

            個人拙見。:)

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-07 09:19 by cexer
            @eXile
            你說它沒有更高階的抽象,大概是因為你在代碼里看到了一些 windows 上的類型。不過類型都是可以 typedef 的,消息值是可以 define 的。這個框架雖然是針對 windows 平臺的,寫這個框架的目的是嘗試一種新的方式,對所有消息驅(qū)動的系統(tǒng)都是適用的,包括非 GUI 系統(tǒng),或非 windows 平臺。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-07 12:27 by Touchsoft
            @eXile
            LRESULT,這些只是typedef的,我覺得不會影響其適用性。
            我倒對樓主的事件處理機制感興趣:)

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-07 14:40 by RISE
            博主什么時間開放代碼?

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-07 16:15 by 0517

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-07 19:18 by megax
            LPCTSTR, LRESULT這些都是可以定義的,一個文件就搞定了。問題是你做出來的東西的入門容易度,我以前也寫過一些封裝,在消息操作系統(tǒng)中,其實就是消息的封裝。封裝消息還是有很高的技巧性的。MFC單純用代碼和宏來做,覺得也挺經(jīng)典的

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-07 19:42 by cexer
            @megax
            這種方式的消息處理,要比 MFC 簡單直接吧。你看到那么多的模板參數(shù),最終的使用者是不會接觸到的,都是框架用于擴展自身的。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-08 08:40 by yhm
            沒看明白,樓主的消息機制是怎么整的。

            # re: 自己寫的一個GUI框架的消息機制[未登錄]  回復(fù)  更多評論   

            2008-08-08 11:25 by eXile
            @cexer
            呵呵,也許我沒有表達清楚,我說的“局限于native win32的思維方式”,是指局限于win32本身的GUI組件設(shè)計,而沒有利用OOP技術(shù)和模式進行更好的組件與消息封裝策略,也就不能消除win32 GUI 設(shè)計本身的復(fù)雜性。這種設(shè)計到頂,也不過是一個改良版的WTL(可以參考 http://www.winxgui.cn/)。當然,它可以適用在性能要求較高的場合,這個,取決于樓主的目標了。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-08 13:07 by cexer
            @eXile
            這倒是的.你說的這個問題,JLIB2(一個 C++ 版的 AWT )就解決得很好,因為設(shè)計方式都是 java 的,所以和 WTL,MFC 之類的大大的不同.不過它大量地使用虛函數(shù),存在性能問題.WinX 這個庫的代碼我也看過,它在 GUI 上幾乎沒有任何的創(chuàng)新,不能說它是一個獨立的 GUI 框架.只能說是對 WTL 的小修補.

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-09 02:50 by 陳梓瀚(vczh)
            WinX好像官方也說就是對WTL進行擴展的吧。我目前也在封一個GUI,想把它變成現(xiàn)在RAD們的外觀。當然我只care外觀而已。譬如要求event可以bind和unbind全局函數(shù)或者成員函數(shù)等,這個已經(jīng)做了。vista底下的控件有31個WindowClass。為什么我不想用消息呢,因為控件所有的私有事件全都是通過WM_COMMAND和WM_NOTIFY發(fā)送給parent control的,所以到時候用起來會特別惡心。

            不過我的GUI原本的目的是給我自己用的,到時候也把代碼開了吧。不過還要一段時間,現(xiàn)在才搞定了1/5的控件,封這個很慘的。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-09 11:52 by cexer
            @陳梓瀚(vczh)
            將event bind 到其它類的成員函數(shù),或者全局函數(shù),以前都實現(xiàn)過,不過不是很實用,干脆去掉了.對于全局函數(shù),如果不是無參數(shù)的函數(shù),那么給它提供運行時的參數(shù)是一件麻煩的事.因為設(shè)計框架的時候,并不知道用戶會提供些什么類型的全局函數(shù),如果把這件事給用戶提供,用起來比較麻煩,接口看起來不簡單明了.如果只允許提供特定的參數(shù)數(shù)目的類型,倒是很簡單,不過就不實用了,所以后來就去掉了.
            WM_COMMAND 和 WM_NOTIFY ,或者是其它消息的細節(jié),框架都應(yīng)該封裝起來,不讓最終的用戶接觸.

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-09 18:53 by 陳梓瀚(vczh)
            不理解為什么『如果不是無參數(shù)的函數(shù),那么給它提供運行時的參數(shù)……』event handler是擁有多種類型的,不是一個單獨的類。就像函數(shù)指針一樣,需要什么參數(shù)就聲明什么參數(shù)的event handler。我把c#的方法搬到了c++來主要目的是為了將來GUI Editor好寫。

            不過我后來用宏來聲明event handler了,雖然樣子并不好看。我把listview的代碼貼出來了,你看一下應(yīng)該會了解我是怎么弄的吧。一切為了GUI Editor,囧……

            制造輪子其實跟受罪沒啥區(qū)別,可惜不得不做捏……

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-09 19:35 by cexer
            @陳梓瀚(vczh)
            能夠親手制造一個漂亮性感用起來爽的輪子,再苦再累也值得啊.
            你的意思是一個針對每一個event,都寫一個handler類?
            多謝提供代碼,等我的框架有個成熟穩(wěn)定了,也打算開放代碼.

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-10 00:11 by 陳梓瀚(vczh)
            每一種不同參數(shù)的event都寫一個類,但是我寫了一對宏來高度簡化了這個過程,工作量已經(jīng)可以忽略不計了。

            # re: 自己寫的一個GUI框架的消息機制[未登錄]  回復(fù)  更多評論   

            2008-08-11 10:45 by c++
            對這個話題非常感興趣!
            我是個mfc程序員,對C++ GUI framework認識僅限在mfc,但是覺得這個里面有很多技巧可言,而且現(xiàn)在可以做什么事情!

            希望看到樓主的更多文章,還有vczh

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-14 22:09 by jxfwinter
            關(guān)鍵問題你沒有提到,窗口消息處理函數(shù)生成和注冊.
            ATL/WTL是MESSAGE一系列的宏來生成消息處理函數(shù),通過thrunk機制把預(yù)先注冊的函數(shù)替換成真正的消息處理函數(shù).
            MFC較為霸道,通過消息鉤子來處理.
            SMARTWIN則是通過嵌入一個this指針然后在消息處理函數(shù)中強制函數(shù)類型轉(zhuǎn)換來處理的,雖說比較符合c++規(guī)范,但卻是比較低效的.

            你的子類中沒有生成窗口處理函數(shù),猜測應(yīng)該和SMARTWIN的做法一樣.

            還是ATL/WTL的方法最為高效.而且我覺得WTL的代碼和STL的風格一樣,雖說是一個框架(盡管WTL之父說不是),但卻非常靈活,易于擴展.

            目前我所看到的GUI庫(QT沒看過),WTL個人認為是最好的.

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-16 00:45 by cexer
            @jxfwinter
            你沒有看明白?
            這個框架,函數(shù)定義即注冊,只需要定義函數(shù)即可,已經(jīng)用不著像 MESSAGE_HANDLER 宏,或者類似功能的東西了。這也是與一般的框架最大的不同。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-16 03:38 by jxfwinter
            不是我沒看明白,是你沒懂我說的話,定義即注冊是因為你在基類中已經(jīng)預(yù)先注冊過了,在窗口中嵌入一個this指針和子類的方法聯(lián)系起來,每次消息來了都取出嵌入的指針,達到調(diào)用子類方法的目的,我猜你的做法是這樣,也就和SmartWin做法一樣.
            你上面所放出的代碼只是給出了你如何進行消息解碼,和ON_MESSAGE之類的宏的作用是一樣的,不過你是用模板實現(xiàn).

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-16 16:40 by cexer
            @jxfwinter
            這個東西解釋起來比較麻煩,我也不知道到底你是不是理解的和我想的一樣。和 SmartWin 不大一樣。定義即注冊有兩個意思,一是如果定義了函數(shù)則進行注冊,二是如果沒有定義函數(shù)就不注冊,并不是像你說的在基類里預(yù)先注冊過了。想像一下幾千個消息,要一個個注冊多麻煩。而且預(yù)先注冊的方法,將會限制消息處理函數(shù)的名字。有時間我會把這個消息機制寫幾篇日志出來分析一下實現(xiàn)原理。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-19 09:12 by minji
            每個函數(shù)都是不同的類型,樓主是怎樣實現(xiàn)映射和分派的?

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-19 09:30 by cexer
            @minji
            我會把我的心得和方法寫幾篇日志出來,到時你看看吧。三言兩語也不能說清楚。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-25 21:44 by proguru
            cexer,把你的消息分派原理分析一下吧,把關(guān)鍵代碼貼出來看看。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-08-26 10:23 by cexer
            @proguru
            最近就會寫的。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2008-12-04 17:33 by 溫輝敏
            很棒的嘗試,GUI的消息機制其實也可用于非GUI的模塊間進行消息的傳遞,做得好可以讓各個模塊都不知道其它模塊的存在,每個模塊是個獨立的軟件模塊。只知道自己要拋出什么消息,要處理外界拋出的什么消息,達到這種程度也可以做到類似插件那樣可以很方便的加入新的模塊,就像winamp等可以靈活加入新的插件一樣。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2009-03-17 12:47 by dulton@gmail.com
            很欣賞你用模板特化的方法實現(xiàn)了windows消息的參數(shù)分解這種手法。

            不過我感覺你的框架跟很多框架一樣。都是實現(xiàn)了觀察者模式。注冊后等待消息。特色就在于用模板實現(xiàn)了框架。而沒有用繼承。

            沒有貼出消息路由代碼來。所以對于消息路由不敢妄加評論。消息如果沒有一個合適的路由的話是搞不成成熟的GUI的。

            拙見。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2009-09-14 19:54 by Loaden
            我認為你的方法如果不是在基類中已經(jīng)定義,那是無法實現(xiàn)的!
            能否帖出核心代碼?

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2009-11-02 15:43 by 大車
            呵呵 我也在造車輪,我打算造一個跨平臺的,跨語言的,純粹是邏輯上的。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2009-11-03 17:36 by 溪流
            這種使用方式看上去還是很爽的
            同求消息機制

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2010-02-22 20:12 by lxw
            這個方法我曾想過,總算碰到同仁了。不過有個悲劇的事實,windows有成百上千個消息,而模板是靜態(tài)的,意味你要有成百上千個switch,每個switch對應(yīng)一個消息,像Message<message>這樣是無法編譯的,就算你那樣用,編譯這么多的模版感覺要蠻久的時間。。

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2010-06-03 09:36 by ccsdu2009
            GUI 框架是如此大而復(fù)雜的一個車輪,除了少數(shù)像我這樣的偏執(zhí)狂,誰會愿意累得七竅流血去制作一個可能一開動就會車毀人亡的車輪呢?  
            比喻形象生動啊

            # re: 自己寫的一個GUI框架的消息機制  回復(fù)  更多評論   

            2013-08-10 22:10 by sinian
            有源碼么呵呵
            久久久久久午夜成人影院| 久久综合亚洲鲁鲁五月天| 97超级碰碰碰碰久久久久| 久久精品一区二区| 久久精品亚洲精品国产欧美| 中文字幕久久精品 | 人妻无码αv中文字幕久久琪琪布| 天天躁日日躁狠狠久久| 久久99精品国产99久久| 香港aa三级久久三级老师2021国产三级精品三级在| 久久亚洲色一区二区三区| 亚洲国产精品无码久久久不卡| 久久电影网一区| 麻豆精品久久久久久久99蜜桃| 97久久精品无码一区二区| 久久99精品免费一区二区| 午夜人妻久久久久久久久| 91精品无码久久久久久五月天| 久久亚洲日韩看片无码| 久久精品国产影库免费看| 日日狠狠久久偷偷色综合96蜜桃| 亚洲中文字幕久久精品无码喷水| 国产日韩久久免费影院| 国产精品久久久久久久人人看| 国产精品美女久久久| 久久中文字幕精品| 成人精品一区二区久久久| 亚洲午夜久久久久久久久电影网| 国产免费久久精品丫丫| 7777精品久久久大香线蕉| 精品久久久无码中文字幕天天| 久久青青草原精品国产| 思思久久99热免费精品6| 四虎国产永久免费久久| 99久久精品免费看国产一区二区三区 | 久久精品国产精品亚洲下载| 久久精品欧美日韩精品| 精品久久久一二三区| 精品无码久久久久久国产| 久久亚洲国产精品一区二区| 欧美精品久久久久久久自慰|