众所周知QRichEdir强大在于其图文排（在这里不跟Word、HTML比）Q其中的图替换ؓ(f)动态图的核心问题就归结于如何高效刷新。我们知道GDI操作是最消耗CPU的，所以刷新整个RichEditH口是不可取的，其副作用?x)导致更严重的闪烁问题。解决问题的思\很简单：(x)cM于拖拽时候在屏幕l制异或U，我们的动画重l时不请求RichEditQ而直接在其窗口的DC上绘制当前动dQ此时缺是如何定该OLE的位|，q个是所有问题的关键。先看下面这q图Q?/p>
假定1-5全部都是GIF囄Q非GIF可以暂时无视Q这个后面大家会(x)非常清楚如何处理。在q个q程中，2不见了，?是新出现的。对?新出现时QRichEdit自n肯定?x)触发其Q?/p>
Draw( DWORD dwDrawAspect, LONG lindex, void* pvAspect, DVTARGETDEVICE* ptd, HDC hicTargetDev, HDC hdcDraw, LPCRECTL prcBounds, LPCRECTL prcWBounds, BOOL (__stdcall *pfnContinue)(DWORD_PTR dwContinue), DWORD_PTR dwContinue)
q个时候，我们知道新的GIF囄q入可视区，可以把它d到集合中。对?的动画触发时间到来时Q我们可以确定其位置且与可视区比对，发现其不再可视区Q则从集合中U除。这样就可以得到一个接q于Q略大于Q当前视口中的动L仉合，当有新的动画触发旉到来Ӟ我们可以先检查其是否在可视区Q如果不在则不用GDI操作Q仅仅更新其当前帧。当然这些工作你也可以不做，但是在动L件数量大的时候效率可能略有下降，主要是查扄q程Q烦引、位|）比较耗时?/p>
如何定一个OLE的位|呢Q由于我们插入OLE都用了REO_BELOWBASELINE标志Q也是跟当前行的底部对齐，所以OLE左下角位|的_度对我们来说很重要。看下图Q?/p>
假设图中黑框是一个OLE对象Q其字符索引为CPNQ假定第N+1行的W一个字W烦引ؓ(f)CPN1Q那么OLE左下角坐?{PosFromChar(CPN).x, PosFromChar(CPN1).y }QPosFromCharq个是RichEdit提供的。问题的关键是最后一行怎么计算Q此时没有第N+1行。对于这U特D情况，主要是Y坐标的计，可以q样考虑QY=RichEdit内容高度-滚动条位|。猜? 计算内容高度可能比较耗时Q故QQ的聊天消息显C部分强制在底部加了一行，以避免这U情况出现?/p>
得到左下角位|以后，可能你会(x)觉得׃事大吉了。错Q还有一个关键点Q我们可以通过OLE的接口GetExtent得到其大，然而这个大没有考虑~放比例Q所以你需要根据当前羃放比例进行计，而这个计牵扯到点数运，q程中的来回不仅ȝ而且不精，所以OLE的可视大要想非常精是不能通过计算来的。我们前面知道OLEl制的时候会(x)传入可视范围Q假如我们保存下来是不是可以解决问题了呢？当然Q显Ӟ你可以试试！
q些问题主要原因是RichEdit的很多接口方法没有暴Ԍ而W(xu)in8的SDK?x)做重大升Q很多之前的问题都会(x)变成不是问题Q或许还?x)引h多的新特性，但是动画本n的逻辑q是需要自己实玎ͼ或者会(x)单许多，至于多少我还不清楚Q但是目前来看这U方案效率够！
Cq里Q核心技术应该大白天下，整个q程Q我q求了位|的_և度，q据此获得最可视集合进行刷C化?/p>
最新SDK&DemoQ参见：(x)http://code.google.com/p/im-solution/。希望你?x)喜Ƣ?/p>
先谈下richedit我做的工作，主要是参照QQ的功能进行设计，分ؓ(f)2个部分：(x)texthost和richoleQ前者实现无H口的richeditQ后者实现动L件。这些东西可以说|上可见的鲜有正的Ҏ(gu)论，很多都是饮鸩止(f)之手D，我确信自q手法是非常科学的?br />
目前的实玎ͼ(x)
1.动画控g
2.拯_脓(chung)Q支持QQ互? 支持HTML格式(|页 word{?互? Shell拖放互? dE序的互?br /> 3.H口、无H口控gl一操作接口
4.增强的扩展能?br />
现有的不_完善Q?br /> 1._脓(chung)|页中图像的下蝲q程是堵塞式下蝲
2.炫彩字体完善
3.新闻摘要Q仿QQQOLE实现
效果图：(x)
SDK&Demo下蝲
无论如何Q对现在的设计（架构&E_性）到达了一个满意效果，最的依赖和最通用的编码，觉得可以拿出来show一下。如果?zhn)有Q何徏议都可以在下面提出或者给我emailQ烦要源码除外，技术讲解我?x)尽快展开Q按照之前的大纲Q。M一切都是围lQQ效果实现Qؓ(f)实现IMc聊天展C提供解x案，武装到牙ѝ?img src ="http://www.shnenglu.com/wlwlxj/aggbug/189750.html" width = "1" height = "1" />
]]>
我支持的剪脓(chung)板格式如下：(x)
kFETCINDEXUnicode, // Unicode 文本
kFETCINDEXAnsi, // ANSI 文本
kFETCINDEXDIB, // DIB
kFETCINDEXHDROP, // HDROP
kFETCINDEXHTML, // HTML
kFETCINDEXIMRichEdit, // 自定义格?/span>
};
未来打算扩展的OLEcd如下Q?/span>
kIMRichElementText, // 字符?/span>
kIMRichElementCustomPicture, // 自定义图?/span>
kIMRichElementSystemPicture, // pȝ囄
kIMRichElementFancyCharacter // 炫彩字符
};
旉紧张Q很多细节处理不完善Q上周还初步实现了chromium的windowless版的embedҎ(gu)Q新的一周要努力完善?/span>
效果囑֦下（支持HTML拯咯！Q！Q：(x)
执行文g下蝲
技术讲解会(x)在现在特性细节完成后l箋。扯点别的，lchrome os的shell攑ּweb实现后，fb也們native app而暂~html5Q似乎给html5g一点h。新技术的E_需要一个过E，而商业公司往往看重的是当前的运营、盈利。当然html5本n仅仅是加入了一些语义、植入了一些sdkQ而作为Windows开发者擅长的也是对sdk装而非语言层面的封装，相比之下Qweb斚w我比较热L(fng)html5新特?canvas)来实现UIQ而对于原生的html元素拼凑界面有点怸着门道?/span>
]]>
很近没有更新了，闲话说Q直奔主题?/span>
微Y做Q何技术的思\Q在实现一个标准的时候，往往预留Z个通用的扩展机制。呃Q貌似很多大公司都是如此Q通过扩展把开发者跟自己捆绑。D例：(x)微Y?/span>ie可以嵌入ActiveX控g、可以用BHO扩展Q?/span>richedit中支?/span>OLE扩展。这U扩展机制主要是Z?/span>OLE框架Q这也是微Y操作pȝ框架的基矟뀂开发层面目前的势是，淡化OLE.NETQ有一U无奈叫骑虎难下Q有一U错误叫q众Q在开发^台、技术百花齐放，开发资源极大丰富的今天Q开发者对微Y的依赖已l不那么强烈Q以至于现在?/span>Windows开发者有点小苦|其?/span>C++开发者有一U被抛弃的感觉，扯远了?/span>
谈谈OLE/COM/ACTIVEX的关pR很模糊Q有一些说不清Q有历史原因Q也有普?qing)程度关pR侯捯玩模板有三境界：(x)?x)用标准库，L标准库源码，?x)用模板做设计。我觉得COM相关的也是如此，使用COMlg往往是容易。我的理解：(x)OLE是技术规范，COM是语a规范Q?/span>ACTIVEX则是用这2东东来实做的可服用组件的U谓。对?/span>OLE的支撑主要在MFC库中Q?/span>ATL库则是更Ua(b)?/span>OLE/COM框架?/span>MFC?/span>OFFICE有一衣带水的关系Q?/span>OFFICE的应用框架促使着MFC的发展（早期如此Q但UI斚w早已分道扬镳Q，OFFICE的应用模型也是MFC的应用开发模型?/span>
之所以提?/span>MFC?/span>OFFICEQ只是想说通用的扩展机制没有那么多条条框框Q即便是ACTIVEX框架q种东西。对?/span>OLE实践Q也是微Y最热衷Q其?/span>Windows操作pȝ?/span>OFFICEpd软g要最典型Q其它则很牵强?/span>OLE技术标准接口只有极数是必d玎ͼ而大部分则是可选实现或者部分实玎ͼ其中richedit更是如此?/span>OLEҎ(gu)务器和客L(fng)都做了行范，如果一方（一般是服务器）自行军_如何实施Q则另一方也只需对应实现?/span>
呃，我说了这么多Q只是ؓ(f)了阐q我的险恶用心，或许没h明白?/span>ATL框架定义了四个标准导出函数用于规范注册、反注册、加载、卸载，q些跟实际的OLE功能无关Q尤其是?/span>richedit扩展中。或怽在网上诸多示例中看到?/span>ATL模板创徏一个控件然后如何简单的插入位图׃为掌握了核心U技Q那么我p泼冷水了Q这些东西无兛_局。既?/span>Windows能用OLE搭徏框架Q既?/span>MFC可以实践OLEQ那么我们也可以用纯正的C++代码?/span>OLEQ我的意思无非就是没必要遵@ATLQ也没必要一定去注册一个东西，问题的核心不是这些东西，目前我们仅仅是ؓ(f)了插入一个动甅R?/span>
Richedit是一个不完全?/span>OLE实践Q前面提到能完全实践OLE的框架不多。因?/span>richedit实现了图文排，所以在IM领域很受Ƣ迎Q尤其是早期Q现在基?/span>chromium的扩展或许可以改变现Ӟ?/span>Richedit是一个容器，可以容纳OLE控gq入Q典型的扩展是动画控g。基?/span>ATL框架开发，你可以实C个标准的控gQ但当你面对一个非标准的容器时Q那些条条框框显得不是那么重要，q也是ؓ(f)什么能做好动画控g不容易的原因?/span>
Ҏ(gu)我的调查Q呃Q通过实践Q通过QueryInterface观察Q，我发现实C?/span>richedit中的动画控g只需要实C个接口：(x)IOleObject?/span>IViewObject2Q前者ؓ(f)了融入到richedit环境中，后者ؓ(f)了渲染显C。由?/span>richedit默认只喜好无H口模式Q所以针?/span>IOleInPlaceSiteWindowless之类的，你去实现意义也不大，因ؓ(f)人家容器不认你，当然q有IPersistpd接口Q对于标准的环境有用Q比?/span>IDEQ，但这里ƈ不是很需要，所以认清核心问题能减少很多困惑。更昄的是我的控g没有?/span>ATL框架Q因为此控gq?/span>richedit环境生存的意义也不大Q更有甚者我没必要让使其成ؓ(f)标准Q也没可能）Q仅仅是Z在一个系l中?/span>richedit中更好地展示。实现的接口少Q引入的ȝ少Q这h能ɾ_֊集中在主要问题上?/span>
lg所qͼ我的控g是一?/span>C++c，只实C两个接口Q?/span>
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()
其中大部分接口都可以无视Q因为我们只需要这个控件在richedit中能够占位（长宽Q，能够展示Q效率关键）Q至于其他的可编E、在位激zR对象识别都不重要。我观察?/span>QQ的动LӞ呃，比现在网上流行的要改变很多（|上内容没有与时pQ。现在的`QQ的动L件很单（后面?x)讲q如何找到这个控ӞQ看h只是作ؓ(f)一个占位工P如何触发动画则是?/span>host控制。观其接口：(x)
};
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的作用我不是很理?/span>Q?/span>居然一个接口都没有Q?/span>而后者模p的能够理解一?/span>Q?/span>src大概是动画囄路径Q?/span>autopd是ؓ(f)了动态羃放。现在的QQ只允怸个自定义动画Q依据老衲猜测Q因定义动画往往是截图，比较大，在一行容易引L(fng)?yn)L视图跌。再有其他的属性是Z识别所用，无法推测具体行ؓ(f)?/span>
呃，事情看v来没有那么复杂，的确Q我只实C2个接口，而其中大部分也都是返?/span>E_NOTIMPLQ因?/span>richedit实没有那么标准Q你实现的再标准也无于事。当?/span>richeit也在更新Q?/span>win8?/span>sdk对其改动最大，?/span>win7?/span>sdk也暴露了一些更早的功能Q这或许是目前实现的最大亮点（技术含量，高风险高回报Q一般h难以|信Q?/span>
对于动画控g阐述到此为止Q或许很多h?x)很失望Q但也仅仅如此，因ؓ(f)它本w什么都没有Q尤其是在你真正明白之后Q所以这里或怽?x)很失望Q但是真正的内容p么多Q我也不知怎么La(b)加醋?/span>
最后一个徏议，希望重所有的玩技术的Q?/span>
1、中国官本位思想很严重，技术搞得不错（或许是运气）立马转管?/span>
2、文人相?/span>
3、资本运作，体制q作Q技术作用不明显
4、吃p皮，难以l系理想
大道无ŞQ大韛_壎ͼ牛叉的技术很多都是y工，而真正的产业才是大无畏的研发Q我们只不过在投机取巧?/span>
]]>
Windowsq_上实现时钟的方式五花八门Q你可以使用H口相关?/span>SetTimer来设|一个时钟，也可以自己开辟线E来做等待触发模拟时钟，?/span>Chromium装的要更加C++对象化一些：(x)依托WindowsH口消息Q抽象出延迟d的概c(din)这U手法几q前我也曄考虑q，只是对其中下ơ最短触发时间计以?qing)更新的法和设计都有力不从心，最l得出的是误差很大的_版：(x)选择固定的最时间片为最触发单位，对很的旉间隔误差很明显?/span>
Windows?/span>Timer Queues用来实现高效的异步时钟，比较奇怪的是这l?/span>API用的貌似q不多。我们知道每个进E都有一个默认的U程池，可以在其中执行一?/span>Work ItemsQ时钟队列和{待操作也都?x)用到这个线E池?/span>timer-queue中的timers创徏和销毁都很轻量高效，因此我选择了它?/span>
每个OLE囄对象在设|图片之后，如果发现是多帧的Q就需要启动动画，创徏旉Q?/span>
WaitOrTimerCallback,
callback_parameter_.get(),
image_->GetFrameDelay(current_frame_),
0, WT_EXECUTEDEFAULT));
q里timer_是返回|q回新徏的时钟对象，可以?/span>OLE对象销毁或者回调函Cq行删除Q而删除操作会(x){待回调执行完毕才返回。传?/span>TimerQueue?/span>NULL表示使用pȝ的队列?/span>Period?/span>0表示只触发一ơ，触发旉?/span>image_->GetFrameDelay(current_frame_)。由于回调函?/span>WaitOrTimerCallback是在U程池的U程中执行，所以更新操作需要同步到动画囄的创建线E中?/span>callback_parameter_包含有上一节提?qing)?/span>ThreadState对象以及(qing)动画OLE对象指针Q?/span>ThreadState创徏的时候会(x)同时创徏一个隐藏窗口用于工作者线E向UIU程同步操作Q?/span>
BOOLEAN TimerOrWaitFired) {
ATLASSERT(TimerOrWaitFired == TRUE);
IMRichPicture::CallbackParameter* parameter =
reinterpret_cast<IMRichPicture::CallbackParameter*>(lpParameter);
ATLASSERT(parameter);
parameter->thread_state->UpdatePictureFrame(parameter->picture);
}
下面?/span>UpdatePictureFrame的实玎ͼ(x)
PostMessage(message_window_, kMessageUpdatePictureFrame,
reinterpret_cast<WPARAM>(picture->richedit()),
reinterpret_cast<LPARAM>(picture));
}
q样l一大圈子，是ؓ(f)了利?/span>Timer Queues的同时保证图片的更新操作是在UIU程中执行，因ؓ(f)囄被插入也是发生在UIU程Q即动画控g创徏?/span>UIU程Qؓ(f)了避免加锁带来的ȝ以及(qing)死锁的可能性，不应该轻易去加锁Q尽量利用操作系l提供的基础设施来实现。这里需要注意的是隐藏窗口接收到kMessageUpdatePictureFrame消息ӞricheditH口可能已不存在或者动L件已l销毁，因此使用指针前，需要判断对象是否还存在Q?/span>
IMRichEditImpl* richedit = reinterpret_cast<IMRichEditImpl*>(wparam);
IMRichPicture* picture = reinterpret_cast<IMRichPicture*>(lparam);
if (IMThreadState::current()->HasRichEdit(richedit))
richedit->OnUpdatePictureFrame(picture);
return 0;
}
]]>
首先是图片解码器的选择。一般来讲有几种选择Q?/span>1、组装各U开源库Q如libpng, libjpg, giflib{，支持什么格式就得添加对应的解码器；2、开源解码包Q如freeimageQ没用过但听说也很不错；3?/span>GDI+Q支持图片格式广泛，接口单，性能一般。当然还有其它方式，大抵差不多。我选择的是GDI+Q图便好用，且目前微软支持的OS上都是自带的Q无需发布Q?。对QQ的程序集DLLq行分析Q发现其中诏I了各种解码技术，有直接采用开源库的，也有依赖GDI+的，不知道是历史遗留问题Q还是各个部门之间技术偏好，抑或是另有玄机。扯到技术偏好，让我头疼的就是程序员在项目中随意的引入库Q解军_一个问题，往往看到不同的h用不同的技术，甚至同一个h在不同的目中造不同的轮子Q有时候没法说服别人，只能|了?/span>
GDI+的初始化需要注意一件事情：(x)不要?/span>DLL入口处加载或卸蝲GDI+Q否则会(x)发生锁死现象Q具体可查阅msdn?/span>
考虑到高性能的界面中可能?x)采用多U程UIQ因此我建立?/span>ThreadState?/span>TLS对象Q所有的数据都存储在q个对象中，同步U程消息是通过惯用手法之隐藏窗口来保证。时至今日，或者早1?/span>2q_(d)我才深刻理解mfc库设计时的那?/span>state理l构体的用处?/span>GDI+的初始化?/span>ThreadState构造函C调用Q正好避免了加蝲冲突q个问题?/span>TLS对象的销毁技巧来自谷歌的chromium源码中的base库里?/span>tls实现Q原始出处来?/span>CodeProjectQ?/span>http://www.codeproject.com/threads/tls.asp。嗯Q其实牛逼的E序员也是纵览乾坤，吸取_֍。提?/span>CodeProjectQ顺带提一下我的学?fn)历E，早期疯狂的q个|站Q几?/span>VC斚w的东襉K把玩q，形成了自q点状知识U篏Q类似的?/span>CodeGuru?/span>vckbaseQ现在已l成为广告站了）Q之后是 sourceforge?/span>codegoogle?/span>codeplex 找一些小的项目研IӞ形成自己的线状知识结构；再后来就是大型的源码阅读Q偶?dng)?x)去谷歌讨论组、微软新ȝ看一些疑难杂症问题，构成了自q面状知识体系。每个h都有自己的学?fn)方法论Q这里仅仅是分n我自q。很多东襉K已经看上L些过Ӟ现在的年ȝ序员可能接触的是stackoverflow?/span>github{?/span>
GDI+中的Image是抽象接口，Z方便使用Q增加了一层简易封?/span>IMImageQ主要接口如下：(x)
long AddRef();
long Release();
const std::wstring& uri() const { return uri_; }
UINT frame_count() const { return frame_count_; }
bool IsAnimate() const { return frame_count_ > 1; }
long GetFrameDelay(UINT frame) const;
long GetWidth() const;
long GetHeight() const;
Gdiplus::Image* GetImage(UINT frame);
通过uri加蝲囄Q?/span>GDI+Ҏ(gu)地图片的加蝲非常单，Image::FromFile可以直接q回Q对于网l图片，需要先通过WinINet下蝲到本圎ͼ然后再加载?/span>
׃使用?/span>tls技术，q里的引用计数实现很单，是++?/span>-- 操作。曾l有人告诉我引用技术是Z解决多线E中对象的生命周期问题，我欲与否认。引用计数只是ؓ(f)了解军_象的生命周期问题Q而这U情况往往在多U程中出玎ͼ因此多线E中或多或少?x)用到引用计数?/span>
IMImagecd以简单的q回一?/span>GDI+?/span>Image对象提供的图片信息，?/span>GetImage需要多做一些事情。对于包含多帧图片的文gQ在l制的时候需要通过GDI+?/span>Image::SelectActiveFrameҎ(gu)选择当前帧，该操作非常耗时Q因此在加蝲囄的时候，发现如果是多帧的Q我们需要额外的decode_image_来解码存放每一帧图像，q样除第一ơ渲染比较耗时外，后面的获取都是非常快的?/span>
GetFrameDelay函数是获取某一帧之间的旉间隔Q通过GDI+?/span>PropertyItem可以很容易的获取。需要指出的?/span>PropertyItemcM用v来却不是cȝ方式Q需要手?/span>newZ块内存，所以这里用一个结构体我看更合适，而且q是C风格的?br />
再增加一?/span>IMImageServiceQ管理整个系l中用到?/span>IMImage对象Q接口很单：(x)
void ReleaseImage(IMImage* image);
需要图像就扑֮要，用完之后记得释放卛_?/span>
q样完成了囄的管理，目前来说_用，也非常简单，不是么？
]]>
在我实作的同Ӟ大量使用了搜索引擎和h技术论坛。我没有扑ֈ直接{案Q然而各U扑朔迷ȝU烦L恍恍惚惚带着我走向最l的胜利Q让我再ơ体?x)到成功贵在坚持不懈。在自认为差不多满意的时候，通过跟同事的探讨Q我横下心l追求完，怿自己做的不会(x)?/span>QQ的实现差?/span>
目前完成了大U中的高效动d现部分，q部分耗时1周，另外加上?/span>2周的工作之外旉的技术调用。接口基?/span>IRichEditOleQ也是说只要符?/span>RichEdit实现规范的都支持Q包括窗口的和无H口的。那什么是W合RichEdit实现规范呢，是W合RichEditH口实现的方式，Ҏ(gu)无窗口的RichEdit实现。你可能说我不知道如何实现无H口?/span>RichEditQ这个不要紧Q我以后?x)做。后面的文章我会(x)陆箋把第一部分实现q行详细讲解Q同时实现第二部分?/span>
效果图：(x)
大纲如下Q?/span>
高效动画实现
高效囄理
高效旉
动画控g
高效动画h
拖拽剪切_脓(chung)支持
Process Monitor
QQ动画lg分析
ClipSpy
QQ的剪切板格式分析
IDataObject
Xml序列化反序列?/span>
拖拽
_脓(chung)
OLE扩展
?/span>QQ新闻摘要
...
]]>
研究背景
自职业生涯v到现在，我参与过三个imcM品，其中我主要负责的是界面库开发。众所周知Q?/span>im软g中有一个非帔R要的控g用于消息展示Q实现方式无外乎ZricheditQ目前这一cMؓ(f)主要方式Q代表：(x)QQQ、基?/span>webbrowserQ代表：(x)GTalkQ，可能?x)有ZWebKit的，我没有刻意去搜集。很多时候对于相对简单的情况Q比如在游戏中，完全可以自己l制?/span>
我曾l模仿过GTalk的实现方式，׃当时自己l验Ơ缺以及(qing)与公司写面的h沟通上的问题，效果不是那么满意Q仅仅够用，后来自己d也没再l做q方面研I。机制上q种方式是可行的Q?/span>native端事情不多?/span>
后来的工作中Q主要是Zrichedit在做Q都是安排其他h负责。在开发过E中Q遇到种U问题，用过各种不优雅的“伎俩”Q由于欠~?/span>OLE知识Q做的h很痛苦，找不C。微软官Ҏ(gu)一个例子，然而只披露了用技巧的冰山一角；codeproject也有的可怜的几个例子Q经不住商业化应用；互联|搜索的一些文章大多都是简单的插入囄{，聊胜于无?/span>
《基?/span>Chrome开源提取的界面开发框架》系列文章获得了不少支持Q在提取q程中我自己也成长很多。抽取出来的引擎要想用于商业化开发，我个得欠~的主要是富文本渲染q一块，q我开始研I?/span>richedit。断断箋l，期间各种事情Q几l放弃。后来一个网友在q个问题上又扑ֈ我，临时的帮助他解决问题之后Q不感叹，Z么互联网上找不到一个优雅的解决Ҏ(gu)甚至是深入的介绍Q?/span>
|友megax的文?/span>http://www.shnenglu.com/megax/archive/2012/03/22/168601.html中关于制作编辑器斚w知识提及(qing)?/span>http://www.catch22.net/tuts/neatpad让我着实佩服，老外对待研究的态度真的很严谨，分n的开发性和持箋性方面远q胜于我们。系列文章中的绝大多数概늟识我都接触过Q然而很多没有深IӞl验q远不如文章Mh?/span>
Richedit的研I的大部分知识都?/span>OLE斚w。现在计机的发展，技术的百花齐放Q?/span>Windowsq_不再那么大行光Q?/span>Windows技术也不再那么不可一世，Mfc来被抛弃Q?/span>WindowsE序员诚惶诚恐，新生代早早把自己定位在更炫更hȀ情的技术^台。在Windows Native开发没有彻底失宠前Q我打算把自己死啃得来的OLE知识发挥“余热”Q对richeditq个东西应用?/span>im领域的问题解决一下，希望对其他h有帮助，也希望没有重复造轮子?/span>
研究目标
Richedit?/span>Windows底层的组Ӟ甚至?/span>2004q泄漏的Win2K代码中都没有Q它是独立于editlg的，?/span>edit位于ntuser中，亦相当底层，虽在泄漏代码中出玎ͼ然而抽取出来的可能性不大。从某种角度来讲Q?/span>Reactos 是抄袭的这份代码，明眼人可以从其死灰复燃的更新列表中发觉。很奇怪的?/span>Reactos 的代码中?/span>richeditQ我也移植过Q只是后来发现功能实在太弱，无可用性，遂放弃，至于Wine 是不是抄袭这份代码，我无从得知，也没_֊再去跟踪?/span>
Richedit 的接口相当稳定，我在Win8中试验过完全兼容Q我惛_应该?x)持l很久，所以值得d好研I一把?/span>
《基?/span>Chrome开源提取的界面开发框架》的view框架Q如果能有一?/span>rtf格式的渲染利器，配以ole的展C，我想以成ؓ(f)互联|商业开发的UI解决Ҏ(gu)?/span>
Richedit 机制上来讲?/span>WebKit一P或者应该反q来说?/span>RicheditH口本n是对ITextServices的封装，实现ITextHost接口?/span>ITextServices交互提供q_支持?/span>ITextServices的支持分两大c：(x)Z文本?/span>ITextDocument和基?/span>ole?/span>IRichEditOle。作?/span>ole容器Q提供的功能主要通过实现几个接口完成的，包括Q?/span>IOleClientSite?/span>IAdviseSink?/span>IOleInPlaceSiteQ缺省的Richedit 貌似不支持定位激z，惌辑ֈȀzL果必L持最后一个接口。与剪脓(chung)板和拖拽数据打交道需要支持统一数据传输接口IDataObject?/span>
研究主要参考对象ؓ(f)QQQ目标ؓ(f)Q支持粘贴格式、动?/span>ole控g、定?/span>ole菜单、拖拽、文本操Uc(din)窗?/span>/无窗口的l一支持{，我会(x)在下一列l的大纲?/span>
已做工作
OLE标准提供了大量工业化标准接口以及(qing)J杂的交互规范，事实上除了微软（?/span>officepd产品为典范）Q鲜有Y件全盘实施。可以说MFC的大部分工作都是用在实现OLEQ所以其臃肿大抵源于此，不得不臃肿，早些q我接触wtl后得出，MFC - WTL == OLEQ或许还有一些打印等斚w设施Q但我不觉得q些是主要特性。以我现在眼光来看待Q把MFC拆分开Q其集合cR打印框架?/span>COM支持?/span>OLE支持、文?/span>/视图/框架模板Q尽现在用的极，大多在行业Y仉域）、进E?/span>/U程/模块状态管理等Q都q不错，?/span>…Q貌似我快把它说全了Q不好意思，我的老毛病又犯了Q其实在心底Q我q有那么一点不舍，即便我很多年没有用它开发商业Y件了。我?/span>MFC学到的东西太多太多，以至于我不肯说它的坏话?/span>
再一ơ，我选择了从MFC中抽取代码。我试q直接?/span>MFCQ静态链接以便偷L(fng)不告诉别人，以免“破坏形象”。但我不觉得我能做到Q原因就是整?/span>MFC耦合的比较紧密，我不x者无法用整个框架来对外提供服务Q所以我不得不制造小轮子。我也试q直接实玎ͼ但是工作量还真不，我怕自q不及(qing)Q故再次出看家本领Q顺藤摸瓜，牵出一个支?/span>OLE的最内核，l过1-2周我能腾出的旉Q终于做CQ于是我写下了开，后面我需要把整个思\ȝ出来。下面是一个示例，插入览器，支持定位Ȁz：(x)
q个例子不具备Q何说明性，只是用来试最的OLE内核框架是否可以工作?/span>
试的接口如下：(x)
q一到此ؓ(f)止！依然是闲话多Q干货少。我?x)努力的Q?/span>
]]>