Direct UI

有个坑爹的说法：其实Direct UI只是一个思想，要实现这个思想，还要靠自己。   

采用windows方式用api或gdi实现ui的绘制。

DirectUI意为直接在父窗口上绘图(Paint on parent dc directly)。

子窗口不以窗口句柄的形式创建，只是逻辑上的窗口，绘制在父窗口之上。

DirectUI技术的实现步骤和难点：
1、窗口的子类化，截获窗口的消息。
2、封装自己的控件，并将自己的控件绘制到该窗口上
3、封装窗口的消息，并分发到自己的控件上，让自己的控件根据消息进行相应和绘制
4、根据不同的行为发送自定义消息给窗口，以便程序进行调用。
5、一般窗口上控件的组织使用XML来描述

 首先，要实现一个好的DirectUI，必须设计出一套逻辑性、可编程性及可扩展性非常强的层布局器(Layout Manager )，为什么这样说呢？
因为DirectUI的核心设计思想就是界面自绘，既然很多控件都要用自绘的形式表现在界面上，那么控件与控件之间，一定存在某些逻辑布局上的依赖关系，我们可以把一个app分解成3D构架，横向为X，纵向为Y，内外为Z，那么好了，A控件跟B控件的X、Y相同，但是我要实现成B为A打底，成为A的背景（当然A会绘制成透明背景模式），那么A与B之间只存在Z的关系，即层次性。由此可以看出，一个好的Layout Manager是DirectUI绘制必不可少的关键点，可以将UI所要表达的所有控件（windowless，全部需要绘制出来的）层次分明的一一展现。（题外话：你可以通过任何手段将控件的逻辑位置等信息解析到LM中）

其次，ReDraw，第一点我已经阐明了控件之间层的关系，接下来自然是要通过LM(Layout Manager)将控件一一表现到界面上。如果在你的项目中木有LM，那么你就惨了，你无法判断应该用什么顺序依次往你的程序界面上绘制控件：(，就像一张空白的画纸，而你想往上面画很多漂亮的猫猫狗狗，那究竟是先画猫还是先画狗呢。。。打住，通过LM，你完全很清楚先画什么后画什么，LM设计的时候可以要求传入控件要有父控件节点，哦可！那么在ReDraw的时候，先遍历LM，绘制父节点，再绘制子节点，这样一来，界面就基本具有逻辑雏形了。

  最后，该绘制的控件已经都绘制出来了，剩下唯一需要你实现的就是如何响应用户对这些控件的操作，这个应该不用多说了，无非就是捕获用户当前LButtonDone/LButtonUp等鼠标Click事件及rect，然后根据LM反馈出属于那种控件，以及该控件对应的事件即可。

以下转载地址：http://blog.sina.com.cn/s/blog_4c3b2dc20100s8w6.html

我对Direct UI里面的消息循环的理解。首先Direct UI是在一个大的窗体里面自绘所有的控件，而这里的控件不同与Windows标准控件，因为他们不是CreateWindow出来的，所以就没有句柄。然后，这个大的窗体还是有消息循环的，我们只把这个窗体的系统消息提取出来，进行处理。因为这个窗体里没有系统控件，所以系统消息就相对单一了，只有鼠标，键盘，还有就是这个大窗体的create paint消息等。我们可以通过一个鼠标单击事件来跟踪一下DUI是如何处理消息的。

一个DUI程序启动，先进入 CPaintManagerUI::MessageLoop， 然后在!CPaintManagerUI::TranslateMessage(&msg)这个函数中提取出本窗体的消息，然后进入所有CPaintManagerUI::PreMessageHandler函数，这里我们需要截获快捷键的信息，比如说TAB、ESC等等。接着进入大窗体注册的callback函数__WndProc，处理一下uMsg == WM_NCCREATE 的问题，这段我没看懂，然后跳到CWindowWnd::HandleMessage 这个都是被用户实现类所重载掉，来实现WM_CREATE等一些消息，比如

   if( uMsg == WM_CREATE ) {     
      m_pm.Init(m_hWnd);
      CDialogBuilder builder;
      CControlUI* pRoot = builder.Create(GetDialogResource());
      ASSERT(pRoot && "Failed to parse XML");
      m_pm.AttachDialog(pRoot);
      m_pm.AddNotifier(this);
      Init();
      return 0;
   }
   LRESULT lRes = 0;
   if( m_pm.MessageHandler(uMsg, wParam, lParam, lRes) ) return lRes;
   return CWindowWnd::HandleMessage(uMsg, wParam, lParam);

这里的GetDialogResource()就是返回的XML的页面构成代码，然后就进入了CPaintManagerUI::MessageHandle 现在，我们就要从这里开始处理消息了。处理消息之前，我们调用m_aMessageFilters[i])->MessageHandler去过滤一些消息。然后这里会处理鼠标移动，size paint等一些消息。我们先看一下WM_LBUTTONDOWN的消息处理，首先，获取到鼠标坐标，然后根据这个坐标来找到那个坐标下的控件，如果没有，直接返回，如果有，我们会建一个 event 的结构体，包含消息的type wParam lParam Mousepoint timestamp wKeyState 还有一个pSender的，估计是tooltip之类的，需要获取两次消息。而我们的WM_LBUTTONDOWN里面没有，信息保存完后，我们会调用找到的控件的Event事件。接着，我们来到了

void CButtonUI::Event(TEventUI& event)
{
   if( event.Type == UIEVENT_BUTTONDOWN || event.Type == UIEVENT_DBLCLICK )//按下
   {
      if( ::PtInRect(&m_rcItem, event.ptMouse) && IsEnabled() ) {          //判断是否在区域内，调用IsEnable
         m_uButtonState |= UISTATE_PUSHED | UISTATE_CAPTURED;              //修改外观
         Invalidate();
      }
   }

   if( event.Type == UIEVENT_BUTTONUP )
   {
      if( (m_uButtonState & UISTATE_CAPTURED) != 0 ) {
         if( ::PtInRect(&m_rcItem, event.ptMouse) ) Activate();
         m_uButtonState &= ~(UISTATE_PUSHED | UISTATE_CAPTURED);
         Invalidate();
      }
   }

Invalidate()是触发一次改区域的重绘，在重绘之前，我们先判断鼠标是否在当前区域，然后，修改 一些外观。当UIEVENT_BUTTONUP 事件后，我们会进入Activate()

bool CButtonUI::Activate()
{
   if( !CControlUI::Activate() ) return false;
   if( m_pManager != NULL ) m_pManager->SendNotify(this, _T("click"));
   return true;
}

这里的notify就是Direct UI 内部去相应系统消息所传递的消息了。然后我们看看SendNotify函数

void CPaintManagerUI::SendNotify(CControlUI* pControl, LPCTSTR pstrMessage, WPARAM wParam , LPARAM lParam )
{
   TNotifyUI Msg;
   Msg.pSender = pControl;
   Msg.sType = pstrMessage;
   Msg.wParam = 0;
   Msg.lParam = 0;
   SendNotify(Msg);
}

void CPaintManagerUI::SendNotify(TNotifyUI& Msg)
{
   // Pre-fill some standard members
   Msg.ptMouse = m_ptLastMousePos;
   Msg.dwTimestamp = ::GetTickCount();
   // Allow sender control to react
   Msg.pSender->Notify(Msg);
   // Send to all listeners
   for( int i = 0; i < m_aNotifiers.GetSize(); i++ ) {
      static_cast<INotifyUI*>(m_aNotifiers[i])->Notify(Msg);  //发送给所有接口
   }
}

我们会看到，系统向所有的INotifyUI接口来转发这个消息。好了，那么我们也应该猜到我们去如何接受到这个消息，首先，要实现INotifyUI接口，然后注册，然后实现这个接口

void CSearchPageWnd::Notify(TNotifyUI& msg)
{
   if( msg.sType == _T("click") ) 
   {
      if( msg.pSender->GetName() == _T("ok") ) {
         CStandardPageWnd* pWindow = new CEditPageWnd;
         pWindow->Create(m_hWnd, NULL, UI_WNDSTYLE_FRAME, 0L);
      }
      if( msg.pSender->GetName() == _T("cancel") ) Close();
   }
   CStandardPageWnd::Notify(msg);
}

这里我们要保证name的唯一，因为这是对所有的接口转发的，否则其他相同name的控件也会相应这个消息。

最后，我们来和MFC的消息循环比较一下。没有了标准控件，DUI里面的系统消息就少了很多，而且每个控件也没有自己的消息循环，这样相互操作起来更加容易。而MFC也是想把所有的系统消息统一管理。首先，MFC用CBT的hook截取了标准控件里面的所有消息，然后用偷天换狗日的方法，改写了这个控件的callback函数。这样不同控件的系统消息就可以在一个平台上交流了，而不是只存在在自己的消息循环里面。然后用struct+macro来实现，我们在设计窗口双击一下，就可以添加click的函数。

这样处理click事件的方法确实非常方便，相比Win32的switch，或者说上面DUI的Notify方式的来说。但是，这种的方便，设计起来是非常的麻烦。比如说我们实现click的处理函数，我们要把这个控件的ID和click函数指针，还有相应的参数放在那个struct里面，然后，把所有这样的struct连成一张网。当MFC截获到这个click事件后，遍历这张网，找到对应的函数，传入相应的参数。

大家知道MFC都是基于继承，那么这个消息的传递也要继承，比如说我自己继承的button，我不写onFocus事件，他也会有这个事件。如果消息真的像class一样继承，那就坑爹了。因为要继承，就要用class，而且会有虚函数表，那虚函数表的内存占用就是个问题。所以，MFC用struct,并且，通过一张网来处理继承这样的关系处理得非常巧妙。而从这点我们可以看出，面向对象只是一种思想，与语言无关。你也可以在C里面通过struct来描述面向对象的继承的思想。

说到最后，我也就是对DUI的消息循环简单的描述一下，对于DUI可以控件套控件，还有一些类的组织，还是相当模糊的。以后有时间还会继续了解的。