很近沒有更新了，閑話少說，直奔主題。

 

微軟做任何技術的思路：在實現一個標準的時候，往往預留出一個通用的擴展機制。呃，貌似很多大公司都是如此，通過擴展把開發者跟自己捆綁。舉例：微軟的ie可以嵌入ActiveX控件、可以用BHO擴展；richedit中支持OLE擴展。這種擴展機制主要是基于其OLE框架，這也是微軟操作系統框架的基石。開發層面目前的趨勢是，淡化OLE強調.NET，有一種無奈叫騎虎難下，有一種錯誤叫脫離群眾，在開發平臺、技術百花齊放，開發資源極大豐富的今天，開發者對微軟的依賴已經不那么強烈，以至于現在的Windows開發者有點小苦逼，尤其是C++開發者有一種被拋棄的感覺，扯遠了。

 

談談OLE/COM/ACTIVEX的關系。很模糊，有一些說不清，有歷史原因，也有普及程度關系。侯捷說玩模板有三境界：會用標準庫，讀懂標準庫源碼，會用模板做設計。我覺得COM相關的也是如此，使用COM組件往往是容易。我的理解：OLE是技術規范，COM是語言規范，而ACTIVEX則是用這2東東來實做的可服用組件的稱謂。對于OLE的支撐主要在MFC庫中，而ATL庫則是更純粹的OLE/COM框架。MFC跟OFFICE有一衣帶水的關系，OFFICE的應用框架促使著MFC的發展（早期如此，但UI方面早已分道揚鑣），OFFICE的應用模型也就是MFC的應用開發模型。

 

之所以提及MFC又OFFICE，只是想說通用的擴展機制沒有那么多條條框框，即便是ACTIVEX框架這種東西。對于OLE實踐，也就是微軟最熱衷，其中Windows操作系統和OFFICE系列軟件要最典型，其它則很牽強。OLE技術標準接口只有極少數是必須實現，而大部分則是可選實現或者部分實現，其中richedit更是如此。OLE對服務器和客戶端都做了行為規范，如果一方（一般是服務器）自行決定如何實施，則另一方也只需對應實現。

 

呃，我說了這么多，只是為了闡述我的險惡用心，或許沒人明白。ATL框架定義了四個標準導出函數用于規范注冊、反注冊、加載、卸載，這些跟實際的OLE功能無關，尤其是在richedit擴展中。或許你在網上諸多示例中看到用ATL模板創建一個控件然后如何簡單的插入位圖就以為掌握了核心科技，那么我就要潑冷水了，這些東西無關大局。既然Windows能用OLE搭建框架，既然MFC可以實踐OLE，那么我們也可以用純正的C++代碼玩OLE，我的意思無非就是沒必要遵循ATL，也沒必要一定去注冊一個東西，問題的核心不是這些東西，目前我們僅僅是為了插入一個動畫。

 

Richedit是一個不完全的OLE實踐，前面提到能完全實踐OLE的框架不多。因為richedit實現了圖文混排，所以在IM領域很受歡迎，尤其是早期（現在基于chromium的擴展或許可以改變現狀）。Richedit是一個容器，可以容納OLE控件進入，典型的擴展就是動畫控件。基于ATL框架開發，你可以實現一個標準的控件，但當你面對一個非標準的容器時，那些條條框框顯得不是那么重要，這也是為什么能做好動畫控件不容易的原因。

 

根據我的調查（呃，通過實踐，通過QueryInterface觀察），我發現實現一個richedit中的動畫控件只需要實現二個接口：IOleObject、IViewObject2，前者為了融入到richedit環境中，后者為了渲染顯示。由于richedit默認只喜好無窗口模式，所以針對IOleInPlaceSiteWindowless之類的，你去實現意義也不大，因為人家容器不認你，當然還有IPersist系列接口，對于標準的環境有用（比如IDE），但這里并不是很需要，所以認清核心問題能減少很多困惑。更顯然的是我的控件沒有用ATL框架，因為此控件脫離了richedit環境生存的意義也不大，更有甚者我沒必要讓使其成為標準（也沒可能），僅僅是為了在一個系統中的richedit中更好地展示。實現的接口越少，引入的麻煩越少，這樣才能使精力集中在主要問題上。

 

綜上所述，我的控件是一個C++類，只實現了兩個接口：

 

X_BEGIN_INTERFACE_MAP(IMRichPicture, ObjectRootBase)
  X_INTERFACE_PART(IMRichPicture, IID_IOleObject, OleObject)
  X_INTERFACE_PART(IMRichPicture, IID_IViewObject, ViewObject)
  X_INTERFACE_PART(IMRichPicture, IID_IViewObject2, ViewObject)
X_END_INTERFACE_MAP()

 

 

其中大部分接口都可以無視，因為我們只需要這個控件在richedit中能夠占位（長寬），能夠展示（效率關鍵），至于其他的可編程、在位激活、對象識別都不重要。我觀察了QQ的動畫控件，呃，比現在網上流行的要改變很多（網上內容沒有與時俱進）。現在的`QQ的動畫控件很簡單（后面會講述如何找到這個控件），看起來只是作為一個占位工具，如何觸發動畫則是由host控制。觀其接口：

interface IRichFrameObj : IDispatch {
    };
interface IRichPicObj : IDispatch {
        [id(0x00000001), propput, helpstring("property src")]
        HRESULT src([in] BSTR rhs);
        [id(0x00000002), propput, helpstring("property static")]
        HRESULT na([in] long rhs);
        [id(0x00000003), propput, helpstring("property autoHeight")]
        HRESULT autoHeight([in] long rhs);
        [id(0x00000004), propput, helpstring("property autoWidth")]
        HRESULT autoWidth([in] long rhs);
        [id(0x00000005), propput, helpstring("property maxAutoWidth")]
        HRESULT maxAutoWidth([in] int rhs);
        [id(0x00000006), propput, helpstring("property onerror")]
        HRESULT onerror([in] BSTR rhs);
        [id(0x00000007), propput, helpstring("property objid")]
        HRESULT objid([in] BSTR rhs);
    };

 

IrichFrameObj的作用我不是很理解，居然一個接口都沒有，而后者模糊的能夠理解一些：src大概就是動畫圖片路徑，auto系列是為了動態縮放。現在的QQ只允許一個自定義動畫，依據老衲猜測，因為自定義動畫往往是截圖，比較大，在一行容易引起點擊時視圖跳躍。再有其他的屬性是為了識別所用，無法推測具體行為。

 

呃，事情看起來沒有那么復雜，的確，我只實現了2個接口，而其中大部分也都是返回E_NOTIMPL，因為richedit確實沒有那么標準，你實現的再標準也無濟于事。當然richeit也在更新，win8的sdk對其改動最大，但win7的sdk也暴露了一些更早的功能，這或許是目前實現的最大亮點（技術含量，高風險高回報，一般人難以置信）。

 

對于動畫控件闡述到此為止，或許很多人會很失望，但也僅僅如此，因為它本身什么都沒有，尤其是在你真正明白之后，所以這里或許你會很失望，但是真正的內容就這么多，我也不知怎么添油加醋。

 

最后一個建議，希望尊重所有的玩技術的：

1、中國官本位思想很嚴重，技術搞得不錯（或許是運氣）立馬轉管理

2、文人相輕

3、資本運作，體制運作，技術作用不明顯

4、吃飽肚皮，難以維系理想

 

大道無形，大音希聲，牛叉的技術很多都是巧工，而真正的產業才是大無畏的研發，我們只不過在投機取巧。