青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

cexer

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

自己寫的一個(gè)GUI框架的消息機(jī)制

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

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

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

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

  我想 SmartWin 和 win32gui,WTL 這些庫(kù)那么出名,更多地是因?yàn)樗鼈儗⒁恍┓浅S袆?chuàng)意的手法運(yùn)用到了 GUI 框架當(dāng)中,想必以后的 GUI 框架都會(huì)多少受其影響。

  看這些庫(kù)都是為了“師夷長(zhǎng)技“,因?yàn)槲易约悍浅O矚g寫 GUI 框架,沒完沒了反反復(fù)復(fù)地寫。

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

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

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

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

 

進(jìn)入正題:

  介紹一下自己在寫的一個(gè) GUI 框架。

  這個(gè)框架是以前幾個(gè)版本的進(jìn)化版,它的消息處理機(jī)制比較有意思。下面是這個(gè)框架的消息映射部分的一個(gè)測(cè)試代碼,從這個(gè)代碼里可以看出來這個(gè)框架在消息處理上的一些創(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: }


消息自動(dòng)映射

  不像 MFC,ATL 那樣的 BEGIN_MESSAGE_MAP ,MESSAGE_HANDLER 之類的一大堆宏來湊成一個(gè)巨大函數(shù),也沒有像 QT 那樣的 connect(xxxx,xxxx) 的顯示連接信號(hào)和槽的代碼,你在上面的測(cè)試代碼里找不到任何的映射痕跡,但是它的確工作得非常好。在這個(gè) GUI 框架當(dāng)中,你只需要定義消息處理函數(shù),框架就能自動(dòng)地幫你映射。例如上面定義的函數(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 消息的時(shí)候,會(huì)自動(dòng)地調(diào)用這個(gè)函數(shù)。

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

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

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

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

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


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

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


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

   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: };


  用這個(gè)模板同樣可以完成上面那個(gè) ID 為 IDOK 的按鈕的點(diǎn)擊事件的處理,并且進(jìn)一步地從消息當(dāng)中分解出了按鈕對(duì)象的指針:

   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ù)名。例如還是那個(gè)按鈕點(diǎn)擊事件的處理函數(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: }


消息的手動(dòng)映射:

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

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

  例如要處理名為 button1 和 button2  的按鈕的點(diǎn)擊事件:

   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: }


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


消息參數(shù)分解

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

   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: }


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

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

  有兩種方法可以針對(duì)不同的消息以不同的方式分解參數(shù),一個(gè)模板的特化。在這個(gè)例子當(dāng)中,WidgetMessage<WM_SIZE> 實(shí)際上就是是對(duì)模板 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 模板是一個(gè)提供消息自動(dòng)映射的基類,所有需要自動(dòng)映射的消息均從此模板派生,并且WidgetMessageBase 保存了三個(gè)未經(jīng)加工的原始參數(shù):

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


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

   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: };


  再舉例針對(duì) 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 當(dāng)中分解出了需要的參數(shù)。然后在消息處理函數(shù)當(dāng)中可以這樣使用:

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


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

  還有一個(gè)分解參數(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é):

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

Feedback

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

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

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

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

個(gè)人拙見。:)

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

2008-08-07 16:15 by 0517

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

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

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

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

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

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

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

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

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

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

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

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

沒有貼出消息路由代碼來。所以對(duì)于消息路由不敢妄加評(píng)論。消息如果沒有一個(gè)合適的路由的話是搞不成成熟的GUI的。

拙見。

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

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

# re: 自己寫的一個(gè)GUI框架的消息機(jī)制  回復(fù)  更多評(píng)論   

2013-08-10 22:10 by sinian
有源碼么呵呵
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            亚洲福利免费| 亚洲欧美日韩一区二区| 中国亚洲黄色| 夜夜嗨av一区二区三区免费区| 亚洲第一精品电影| 伊人成人在线视频| 亚洲高清av| 亚洲精品婷婷| 亚洲一二三区精品| 亚洲免费一级电影| 欧美诱惑福利视频| 蜜臀av在线播放一区二区三区| 欧美国产日韩一区二区三区| 亚洲国产欧美一区二区三区久久 | 久久精品五月婷婷| 性娇小13――14欧美| 欧美一级电影久久| 美女在线一区二区| 欧美日韩一区二区视频在线 | 欧美国产国产综合| 欧美日韩国产区一| 国产精品视频成人| 樱花yy私人影院亚洲| 99热这里只有成人精品国产| 校园春色国产精品| 久久在精品线影院精品国产| 亚洲黄色高清| 久久精品国产亚洲5555| 欧美激情一区二区三级高清视频| 国产精品视频一区二区高潮| 亚洲风情亚aⅴ在线发布| 亚洲一区尤物| 欧美成人午夜| 午夜精品久久久久久久99水蜜桃| 久热国产精品| 国产乱人伦精品一区二区| 亚洲高清不卡| 欧美呦呦网站| 99精品99| 免费在线成人| 韩国av一区| 亚洲欧美日本国产有色| 亚洲丰满在线| 久久精品二区三区| 国产精品自拍在线| 亚洲视频精选| 亚洲精品久久久久中文字幕欢迎你 | 亚洲国产欧美另类丝袜| 欧美一区二区三区免费在线看| 欧美日韩福利视频| 亚洲国产成人精品久久| 久久激情婷婷| 亚洲在线播放| 欧美日韩91| 日韩视频久久| 91久久精品日日躁夜夜躁欧美 | 国产精品一区二区男女羞羞无遮挡 | 欧美午夜精品理论片a级大开眼界| 亚洲国产精品久久人人爱蜜臀 | 亚洲国产99| 欧美一级片一区| 国产精品久久久久77777| 亚洲午夜激情| 99国产精品久久久久久久成人热 | 久久综合中文| 久久国产综合精品| 国内外成人免费激情在线视频网站| 亚洲欧美日韩精品一区二区| 亚洲精品一区二区在线| 欧美看片网站| 一区二区三区欧美在线观看| 日韩一级片网址| 欧美系列亚洲系列| 午夜精品成人在线视频| 亚洲天堂久久| 国产一区二区毛片| 久久久久综合网| 久久精品二区三区| 亚洲黄色av| 日韩亚洲欧美中文三级| 国产精品久久久久影院色老大| 欧美一区二区精品久久911| 欧美一级视频一区二区| 在线电影一区| 最新成人在线| 国产精品久久久久久久午夜片| 欧美在线一二三区| 久久久亚洲午夜电影| 亚洲日本欧美| 一区二区三区四区五区在线| 国产真实乱偷精品视频免| 欧美激情视频一区二区三区不卡| 欧美日韩三级电影在线| 日韩视频在线一区二区| 国产精品99久久久久久久女警 | 亚洲欧美另类综合偷拍| 欧美亚洲在线播放| 亚洲日本激情| 欧美一级专区| 亚洲图片欧美午夜| 久久天天躁狠狠躁夜夜av| 一本一本久久a久久精品综合妖精| 亚洲男人第一网站| 99在线精品视频| 久久久免费av| 欧美一区二区视频在线观看| 欧美第十八页| 久久综合狠狠| 国产精品综合久久久| 亚洲日本在线观看| 黄色成人免费网站| 亚洲一区二区三区在线观看视频| 亚洲日本va午夜在线电影| 久久9热精品视频| 亚洲午夜精品久久| 久久久精品免费视频| 久久久噜噜噜久久狠狠50岁| 日韩一级在线| 免费观看亚洲视频大全| 久久国产66| 国产精品草莓在线免费观看| 亚洲高清av| 亚洲欧洲精品一区| 久久久久久久久伊人| 欧美在线三区| 国产精品视频精品| 99在线|亚洲一区二区| 亚洲动漫精品| 性伦欧美刺激片在线观看| 性久久久久久久久久久久| 老司机一区二区三区| 欧美亚洲一区二区在线| 亚洲视频久久| 亚洲欧美国产日韩中文字幕| 久久亚洲综合色| 亚洲午夜精品17c| 欧美日韩国产高清| 99国产一区| 亚洲视频一区二区免费在线观看| 午夜在线观看欧美| 亚洲一区二区三区激情| 欧美高清在线一区二区| 欧美韩国日本一区| 韩国免费一区| 欧美sm重口味系列视频在线观看| 久久九九国产| 国产精品推荐精品| 一区二区日韩| 亚洲激情婷婷| 久久一区欧美| 另类综合日韩欧美亚洲| 国产综合久久| 亚洲毛片在线免费观看| 亚洲曰本av电影| 欧美日韩中国免费专区在线看| 亚洲国产精品传媒在线观看 | 性久久久久久久| 亚洲影院在线| 欧美三级网址| 午夜精品久久久久久久蜜桃app| 亚洲一区二区精品在线| 欧美视频中文字幕在线| 99香蕉国产精品偷在线观看| 一区二区三区国产精华| 国产欧美日韩另类一区| 性欧美暴力猛交另类hd| 久久精品理论片| 韩国免费一区| 亚洲综合社区| 亚洲春色另类小说| 一区二区三区国产| 国产精品二区二区三区| 亚洲网站视频| 亚洲东热激情| 亚洲男人av电影| 国产在线不卡视频| 久久青草久久| 在线成人av| 国产精品视频久久| 久久综合亚州| 99热免费精品| 日韩亚洲欧美成人| 亚洲视频网站在线观看| 国产精品一区二区在线| 午夜在线一区二区| 亚洲人成在线播放网站岛国| 亚洲一本视频| 经典三级久久| 欧美日韩1区| 米奇777超碰欧美日韩亚洲| 亚洲精品免费在线观看| 午夜在线成人av| 亚洲国产日韩美| 免费h精品视频在线播放| 香港久久久电影| 亚洲日本成人女熟在线观看| 久久精品99| 影音先锋国产精品| 国产午夜精品一区理论片飘花 | 亚洲一区自拍|