1. 项目概述与核心价值最近在整理老项目时翻出了一个尘封已久的宝藏——一套我早年基于VCVisual C开发的富文本控件源代码及完整示例。这可不是网上那些东拼西凑的Demo而是一个真正在多个商业项目中打磨过、功能全面、可直接集成使用的成熟解决方案。如果你正在为MFC或Win32桌面应用寻找一个稳定、灵活且功能强大的文本编辑或显示组件这套代码或许能让你少走很多弯路。富文本控件简单说就是能处理带格式文本如字体、颜色、图片、表格的编辑框或显示区域。在Web开发中我们有div contenteditable和各种前端库但在原生的Windows桌面开发领域尤其是VC环境下一个功能完善的富文本控件往往是项目中的“硬骨头”。系统自带的CRichEditCtrl功能有限且定制困难第三方商业控件又可能带来授权和兼容性问题。因此拥有一套自己可控的、高质量的源代码其价值不言而喻。这套代码不仅解决了基础的富文本显示与编辑还深入处理了光标定位、撤销重做、OLE对象嵌入、打印预览等高级特性并附带了详尽的示例程序展示了从基础集成到高级定制的完整路径。2. 控件核心架构与设计思路拆解2.1 为何选择自研而非使用现有控件在项目初期我们评估了多个选项。标准的MFCCRichEditCtrl是首选但它对复杂格式如自定义背景、嵌入式控件的支持不足且其底层APIRich Edit 2.0/3.0的文档相对晦涩扩展性差。像Scintilla这类开源编辑组件更侧重于纯文本或代码编辑富文本支持并非其强项。商业控件如TX Text Control或ComponentOne确实强大但高昂的授权费用和可能存在的运行时依赖对于需要深度定制和严格控制发布包大小的项目来说是个不小的负担。因此我们决定基于Windows GDI和OLE技术栈从底层开始构建一个轻量级但功能完备的富文本引擎。核心设计目标有三个一是高性能要能流畅处理数万行带格式文本二是高可扩展性架构上要能方便地添加新格式如自定义标记、数学公式三是易用性提供类似MFC的类封装和清晰的接口降低集成复杂度。2.2 核心架构分层解析整个控件采用了经典的三层架构确保了逻辑清晰和模块间的低耦合。文档模型层 (Document Model Layer)这是整个控件的“大脑”。我们设计了一个基于“段落-字符”的树状结构来存储富文本内容。每个段落(CTextParagraph)是一个容器包含多个字符运行(CTextCharRun)。字符运行是格式应用的最小单位它关联了一组格式属性字体、颜色、下划线等和实际的文本内容。这种设计比为每个字符单独存储格式要高效得多尤其是在处理大段相同格式的文本时。文档模型还独立于视图这意味着同一份文档数据可以被多个视图如编辑视图、打印预览视图同时显示。视图渲染层 (View Rendering Layer)这一层负责将文档模型“画”到屏幕上。它基于Windows GDI进行所有绘制操作。核心类是CTextView它计算每个字符、每个段落在视图坐标系中的位置布局计算并调用GDI函数进行绘制。为了提升渲染性能我们实现了增量渲染和脏矩形更新机制。即只重绘屏幕上发生变化的区域而不是整个客户区。对于复杂元素如图片或嵌入式OLE对象视图层会创建并管理相应的GDI位图或OLE视图对象。用户交互与命令层 (User Interaction Command Layer)这一层处理所有用户输入键盘、鼠标并将其转化为对文档模型的操作。我们实现了完整的命令模式(Command Pattern)。每一个用户操作如输入字符、删除文本、设置格式都被封装成一个独立的命令对象如CInsertTextCommand,CSetFontFormatCommand。这些命令对象可以被执行、撤销(Undo)和重做(Redo)。命令管理器(CCommandManager)维护着一个命令历史栈这是实现强大撤销重做功能的基础。这种设计也使得宏录制、自动化脚本等功能更容易实现。3. 关键功能模块深度解析与实现3.1 文本格式管理与样式系统富文本的核心在于格式。我们实现了一个灵活且高效的样式系统。字符格式与段落格式分离格式被明确分为两类字符格式和段落格式。字符格式作用于选中的文本范围包括字体族、大小、粗体、斜体、颜色、背景色、下划线类型等。段落格式则作用于整个段落包括对齐方式左、中、右、两端、缩进左缩进、首行缩进、右缩进、行距以及段前段后间距。这种分离符合用户的直觉操作也便于内部管理。样式继承与覆盖机制为了减少冗余存储我们引入了“默认样式”和“样式覆盖”的概念。控件初始化时会加载一套默认的字符和段落样式。当用户对某段文本应用新格式时我们并不修改原始的字符运行而是创建一个新的字符运行它继承自原运行并覆盖指定的属性。这样即使频繁修改格式内存增长也是可控的。所有样式信息通过一个CTextFormat类进行管理该类使用LOGFONT和PARAFORMAT2等Windows原生结构并与GDI资源如HFONT进行高效转换和缓存。实操心得字体缓存优化频繁创建和销毁HFONT是GDI编程的性能杀手。我们建立了一个字体缓存字典以LOGFONT结构为键缓存在HFONT对象。当需要某种字体时先查缓存没有则创建并存入。控件销毁时统一释放所有缓存字体。这个简单的优化让文本渲染速度提升了近30%。3.2 嵌入式对象与OLE支持一个专业的富文本控件必须能处理图片、表格甚至其他应用程序的文档如Excel图表。我们通过OLE对象链接与嵌入技术实现了这一点。OLE对象的插入与激活当用户通过菜单插入一个OLE对象例如“插入-对象-Microsoft Excel图表”时控件会调用OleCreateFromFile或OleCreateNew等API在文档中创建一个“对象站点”。这个站点负责管理OLE对象的生命周期。在视图层对象被渲染为一个带有图标的占位框。双击该对象控件会调用OleActivate启动Excel并就地激活in-place activation该图表进行编辑此时控件的菜单和工具栏会与Excel的合并用户体验无缝。自定义嵌入式控件的实现除了标准的OLE对象我们还支持嵌入自定义的Windows控件比如一个日期选择器或一个按钮。这是通过实现一个特殊的“控件包装器”对象来完成的。该包装器在文档中作为一个特定类型的嵌入式对象存在在渲染时它会在指定位置创建并显示真正的Windows控件如CDateTimeCtrl。我们重写了控件的消息循环确保嵌入控件能正常接收键盘和鼠标消息。这在开发表单填写类应用时非常有用。3.3 撤销重做(Undo/Redo)引擎的实现撤销重做是编辑器的灵魂功能其实现质量直接关系到用户体验。基于命令模式的实现如前所述每一个修改文档的操作都被封装为一个命令对象继承自ICommand接口该接口通常包含Execute(),Unexecute()即撤销以及GetDescription()用于在历史列表中显示等方法。class ICommand { public: virtual ~ICommand() {} virtual BOOL Execute() 0; // 执行命令 virtual BOOL Unexecute() 0; // 撤销命令 virtual CString GetDescription() const 0; // 获取描述 }; class CInsertTextCommand : public ICommand { private: CString m_strText; CPos m_insertPos; CTextDocument* m_pDoc; public: CInsertTextCommand(CTextDocument* pDoc, const CPos pos, const CString text); virtual BOOL Execute() override { // 在m_insertPos处插入m_strText return m_pDoc-InsertText(m_insertPos, m_strText); } virtual BOOL Unexecute() override { // 从m_insertPos处删除长度为m_strText.GetLength()的文本 return m_pDoc-DeleteText(m_insertPos, m_strText.GetLength()); } virtual CString GetDescription() const override { return _T(插入文本); } };命令的合并与压缩如果用户连续输入字符每一个按键都生成一个CInsertTextCommand这会导致历史栈迅速膨胀且撤销时是一个字符一个字符地删除体验很差。我们实现了命令合并当新命令与栈顶命令是同一类型如连续插入且满足一定条件如插入位置相邻时将新命令合并到栈顶命令中。例如连续输入“hello”会合并成一个“插入hello”的命令而不是五个独立的命令。历史栈的管理与内存考量CCommandManager管理两个栈撤销栈(Undo Stack)和重做栈(Redo Stack)。执行新命令时将其压入撤销栈并清空重做栈。我们为历史栈设置了内存上限和步数上限。当超过限制时会丢弃最旧的命令。对于占用内存大的命令如插入大图片其内部会存储差异数据而非完整数据副本以节省内存。4. 控件集成与高级功能实战4.1 基础集成从零构建一个简单的文本编辑器让我们通过一个最简单的示例看看如何将这套控件集成到你的MFC对话框中。第一步将源代码加入工程将控件的所有.h和.cpp文件通常包括CRichTextCtrl.h/cpp,CTextDocument.h/cpp,CTextView.h/cpp等核心类添加到你的VC工程中。确保你的工程设置中#include路径能正确找到这些文件。第二步在对话框中放置控件在资源编辑器中为你想要放置富文本编辑器的对话框添加一个自定义控件(Custom Control)。设置其Class属性为“CRichTextCtrl”这是我们导出的窗口类名。并给它一个ID比如IDC_RICH_TEXT。第三步关联控件变量并进行初始化在对话框类的头文件中声明一个控件变量。注意我们使用DDX_Control进行动态绑定。// 在对话框类声明中 class CMyDialog : public CDialog { // ... private: CRichTextCtrl m_wndRichEdit; // 富文本控件对象 // ... };在CMyDialog::DoDataExchange函数中进行数据交换绑定void CMyDialog::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); DDX_Control(pDX, IDC_RICH_TEXT, m_wndRichEdit); // 关键绑定 }在CMyDialog::OnInitDialog()函数中我们可以对控件进行初始化比如设置默认字体、加载初始文本。BOOL CMyDialog::OnInitDialog() { CDialog::OnInitDialog(); // 设置默认字体 LOGFONT lf {0}; _tcscpy_s(lf.lfFaceName, _T(宋体)); lf.lfHeight -12; // 12像素高 m_wndRichEdit.SetDefaultFont(lf); // 加载一些带格式的文本 m_wndRichEdit.SetWindowText(_T(这是一个b加粗/b和colorFF0000红色/color的示例。)); // 注意实际API可能是SetText或LoadFromRTF这里为示意。 return TRUE; }第四步处理控件通知消息富文本控件在内容改变、选择改变时会向父窗口发送通知消息。我们需要在对话框的消息映射中处理它们。BEGIN_MESSAGE_MAP(CMyDialog, CDialog) ON_NOTIFY(RTN_TEXTCHANGED, IDC_RICH_TEXT, OnRichTextChanged) // 自定义通知码 ON_NOTIFY(RTN_SELCHANGE, IDC_RICH_TEXT, OnRichTextSelChange) END_MESSAGE_MAP() void CMyDialog::OnRichTextChanged(NMHDR* pNMHDR, LRESULT* pResult) { // 文本内容发生变化时的处理 UpdateData(FALSE); // 可能需要更新其他UI *pResult 0; } void CMyDialog::OnRichTextSelChange(NMHDR* pNMHDR, LRESULT* pResult) { // 选择区域发生变化更新格式工具栏状态 CHARFORMAT2 cf; m_wndRichEdit.GetSelectionCharFormat(cf); // 根据cf.dwMask和cf.dwEffects更新UI按钮加粗、斜体等的按下状态 *pResult 0; }至此一个具备基本编辑和格式显示功能的富文本编辑器就集成完毕了。你可以通过调用m_wndRichEdit的一系列成员函数如SetBold,SetFontName,InsertImage来实现更复杂的操作。4.2 高级功能实现打印与打印预览打印是桌面应用的重要功能。我们的控件内置了完善的打印和打印预览支持。分页计算与绘制打印的核心是将文档内容合理地分配到多页纸上。我们在CTextDocument中实现了一个CPaginator分页器类。它的工作流程如下获取打印机DC根据用户选择的打印机和纸张设置创建一个与打印机兼容的设备上下文(DC)。计算页边距和可打印区域考虑纸张大小、打印机物理边距和用户设定的页边距计算出每页实际可用于打印文本的矩形区域。遍历文档进行分页从文档开头开始模拟在打印DC上绘制每一行。使用GetTextExtentPoint32等GDI函数精确计算每行文本在打印分辨率下的高度。当累计高度超过当前页的可打印区域高度时就插入一个分页符并记录该页的起始段落和行号。这个过程会生成一个“分页信息”列表。生成打印预览打印预览的本质是在屏幕DC上按照缩放比例模拟绘制每一页的内容。我们创建一个内存位图按照屏幕DPI和缩放比例将一页的内容绘制到位图上然后显示出来。通过缓存已渲染的预览页位图可以快速响应用户的翻页操作。打印任务的执行当用户点击打印时我们启动一个打印任务调用StartDoc开始一个打印作业。遍历之前计算好的分页信息列表对每一页 a. 调用StartPage开始新的一页。 b. 将打印机DC传入控件的渲染层并告诉渲染器只绘制属于当前页的文档范围。 c. 调用EndPage结束本页。所有页绘制完成后调用EndDoc结束打印作业。注意事项打印机与屏幕的DPI差异这是打印中最容易出错的地方。屏幕DPI通常是96而打印机DPI可能是300、600甚至更高。所有涉及尺寸的计算字体大小、边距、图片缩放都必须基于当前DC的DPI进行转换。我们的做法是在分页和绘制时传入一个“缩放比例”因子这个因子是打印机DPI / 屏幕逻辑DPI。字体大小等逻辑单位需要乘以这个因子转换成物理单位例如12磅字体在300 DPI打印机上其lfHeight需要按比例计算。忽略这一点会导致打印出来的文字非常小或布局错乱。4.3 性能优化与大规模文本处理当文档内容达到数万行甚至更多时性能成为关键挑战。我们采用了以下策略虚拟化渲染与延迟加载对于超长文档一次性计算所有行的布局并渲染是不可行的。我们实现了类似列表控件虚拟化的技术。控件只计算和渲染当前可见区域及前后少量缓冲区域内的行。当用户滚动时动态计算新进入视图的行并渲染。对于嵌入式的大图片或OLE对象采用缩略图先行加载完整内容按需加载的策略。增量式布局计算文档的布局计算确定每行宽度、高度、换行位置是CPU密集型操作。我们将其设计为增量式。当文档某处被修改如插入文本我们只重新计算从修改点开始到受影响的段落结束范围内的布局而不是整个文档。这需要维护一个段落之间的依赖关系但能极大提升编辑响应速度。高效的屏幕刷新我们重写了控件的OnPaint处理采用“脏矩形”技术。只对需要更新的区域如光标闪烁的位置、文本选择变化的区域进行重绘避免全屏刷新带来的闪烁和性能损耗。同时对于连续的快速操作如按住退格键删除进行绘制操作的合并与节流避免UI线程被拖垮。5. 常见问题排查与调试技巧实录在实际使用和集成这套控件的过程中你可能会遇到一些典型问题。以下是我总结的“避坑指南”。5.1 内存泄漏与资源管理在GDI编程中资源泄漏如HFONT,HBITMAP,HPEN是常见问题会导致程序运行一段时间后GDI对象耗尽界面异常。问题现象程序运行一段时间后界面绘制变慢、残缺甚至整个窗口变白。在任务管理器中查看进程的GDI对象数量持续增长。排查与解决使用工具利用Visual Studio的诊断工具或专门的GDI泄漏检测工具如GDIView来监控进程的GDI对象句柄数量。遵循“谁创建谁销毁”原则确保每一个CreateFont,CreateBitmap,CreatePen等调用都有对应的DeleteObject。最好将GDI资源封装在C类中利用RAII资源获取即初始化机制在析构函数中自动释放。检查缓存机制我们实现的字体缓存等机制必须在控件销毁时如WM_DESTROY消息中确保清空缓存并释放所有缓存的GDI对象。一个常见的错误是只清空了缓存的数据结构忘了释放实际的HFONT。OLE对象泄漏嵌入式OLE对象如果未正确释放会导致更严重的内存泄漏。确保在文档清除或控件销毁时遍历所有嵌入式对象站点并调用OleSetContainedObject和Release。5.2 光标闪烁与绘制异常问题现象光标不闪烁、闪烁频率异常或者在滚动、缩放后光标位置显示错误。排查与解决光标定时器光标闪烁是通过一个Windows定时器(SetTimer)实现的。确保在控件获得焦点时启动定时器(KillTimer)失去焦点时销毁定时器。定时器消息处理函数中应反转光标所在位置的绘制通过异或操作并强制重绘光标矩形区域。光标位置计算光标的位置行、列必须根据当前文档布局、滚动偏移和缩放比例精确计算为屏幕坐标。任何影响布局的操作如插入删除文本、改变窗口大小、缩放后都必须重新计算并更新光标位置。调试时可以输出光标逻辑位置和计算后的屏幕坐标进行比对。双缓冲与绘制顺序如果使用了双缓冲技术来消除闪烁要确保光标是在最后一步绘制到屏幕DC上的否则它可能会被背景覆盖。通常的绘制顺序是先将所有文本和背景绘制到内存位图然后将内存位图拷贝到屏幕DC最后在屏幕DC上绘制光标。5.3 复制粘贴格式丢失问题现象从控件中复制带格式的文本到Word或记事本格式丢失或者从网页复制内容到控件格式混乱。排查与解决剪贴板格式支持富文本控件应同时向剪贴板注册多种格式包括纯文本(CF_TEXT)、富文本(CF_RTF)、HTML(CF_HTML)等。在Copy操作中将当前选中的内容以这些格式分别准备好。在Paste操作中按格式的“丰富程度”优先级如CF_HTMLCF_RTFCF_TEXT从剪贴板获取数据并解析。RTF格式处理RTF是一种复杂的格式描述语言。我们使用了微软提供的RichEdit流输入输出函数如StreamIn,StreamOut来简化RTF的序列化与反序列化。确保在复制时正确调用StreamOut生成RTF字节流在粘贴时调用StreamIn解析RTF流。注意处理字符编码ANSI/Unicode问题。HTML粘贴过滤从网页粘贴的HTML通常包含大量样式和标签。直接全部解析并渲染会非常复杂且可能引入不安全脚本。一个实用的策略是进行过滤只解析和支持一部分安全的、基本的HTML标签和CSS样式如b,i,font color...,p align...忽略其他复杂标签。可以集成一个轻量级的HTML解析库如libxml2的HTML解析模块来辅助这个过程。5.4 与高DPI显示器的兼容性问题问题现象在4K等高DPI屏幕上控件显示模糊或者字体、布局大小异常。排查与解决启用DPI感知在应用程序清单文件(.manifest)中声明DPI感知。对于VC程序通常需要设置为dpiAwareTrue/PM/dpiAware或dpiAwarenessPerMonitorV2/dpiAwareness。这样系统会告知程序真实的DPI值。使用物理像素和逻辑坐标转换所有内部的坐标计算和GDI绘制应基于逻辑坐标。但在获取屏幕尺寸、窗口大小时需要与物理像素进行转换。使用GetDeviceCaps(hdc, LOGPIXELSX)获取DPI并使用MulDiv等函数进行缩放计算。我们的控件在初始化时会查询主屏幕的DPI缩放比例并以此为基础调整默认字体大小、图标尺寸等。资源图像多版本工具栏图标等位图资源应准备多个分辨率版本如16x16, 32x32, 64x64并在运行时根据当前DPI缩放比例加载合适的版本避免拉伸导致的模糊。这套源代码和示例是我多年桌面开发经验的结晶。它可能不像最新前端框架那样光鲜但其稳定、高效和深度可控的特性在需要复杂文档处理、专业排版或与硬件紧密集成的工业级Windows桌面应用中依然有着不可替代的价值。代码中充满了各种针对特定场景的优化和妥协这些“雕琢”的痕迹正是其区别于通用组件的魅力所在。如果你正在面临类似的开发挑战希望这份“遗产”能为你提供一个坚实可靠的起点。
VC++富文本控件开发实战：从架构设计到性能优化
1. 项目概述与核心价值最近在整理老项目时翻出了一个尘封已久的宝藏——一套我早年基于VCVisual C开发的富文本控件源代码及完整示例。这可不是网上那些东拼西凑的Demo而是一个真正在多个商业项目中打磨过、功能全面、可直接集成使用的成熟解决方案。如果你正在为MFC或Win32桌面应用寻找一个稳定、灵活且功能强大的文本编辑或显示组件这套代码或许能让你少走很多弯路。富文本控件简单说就是能处理带格式文本如字体、颜色、图片、表格的编辑框或显示区域。在Web开发中我们有div contenteditable和各种前端库但在原生的Windows桌面开发领域尤其是VC环境下一个功能完善的富文本控件往往是项目中的“硬骨头”。系统自带的CRichEditCtrl功能有限且定制困难第三方商业控件又可能带来授权和兼容性问题。因此拥有一套自己可控的、高质量的源代码其价值不言而喻。这套代码不仅解决了基础的富文本显示与编辑还深入处理了光标定位、撤销重做、OLE对象嵌入、打印预览等高级特性并附带了详尽的示例程序展示了从基础集成到高级定制的完整路径。2. 控件核心架构与设计思路拆解2.1 为何选择自研而非使用现有控件在项目初期我们评估了多个选项。标准的MFCCRichEditCtrl是首选但它对复杂格式如自定义背景、嵌入式控件的支持不足且其底层APIRich Edit 2.0/3.0的文档相对晦涩扩展性差。像Scintilla这类开源编辑组件更侧重于纯文本或代码编辑富文本支持并非其强项。商业控件如TX Text Control或ComponentOne确实强大但高昂的授权费用和可能存在的运行时依赖对于需要深度定制和严格控制发布包大小的项目来说是个不小的负担。因此我们决定基于Windows GDI和OLE技术栈从底层开始构建一个轻量级但功能完备的富文本引擎。核心设计目标有三个一是高性能要能流畅处理数万行带格式文本二是高可扩展性架构上要能方便地添加新格式如自定义标记、数学公式三是易用性提供类似MFC的类封装和清晰的接口降低集成复杂度。2.2 核心架构分层解析整个控件采用了经典的三层架构确保了逻辑清晰和模块间的低耦合。文档模型层 (Document Model Layer)这是整个控件的“大脑”。我们设计了一个基于“段落-字符”的树状结构来存储富文本内容。每个段落(CTextParagraph)是一个容器包含多个字符运行(CTextCharRun)。字符运行是格式应用的最小单位它关联了一组格式属性字体、颜色、下划线等和实际的文本内容。这种设计比为每个字符单独存储格式要高效得多尤其是在处理大段相同格式的文本时。文档模型还独立于视图这意味着同一份文档数据可以被多个视图如编辑视图、打印预览视图同时显示。视图渲染层 (View Rendering Layer)这一层负责将文档模型“画”到屏幕上。它基于Windows GDI进行所有绘制操作。核心类是CTextView它计算每个字符、每个段落在视图坐标系中的位置布局计算并调用GDI函数进行绘制。为了提升渲染性能我们实现了增量渲染和脏矩形更新机制。即只重绘屏幕上发生变化的区域而不是整个客户区。对于复杂元素如图片或嵌入式OLE对象视图层会创建并管理相应的GDI位图或OLE视图对象。用户交互与命令层 (User Interaction Command Layer)这一层处理所有用户输入键盘、鼠标并将其转化为对文档模型的操作。我们实现了完整的命令模式(Command Pattern)。每一个用户操作如输入字符、删除文本、设置格式都被封装成一个独立的命令对象如CInsertTextCommand,CSetFontFormatCommand。这些命令对象可以被执行、撤销(Undo)和重做(Redo)。命令管理器(CCommandManager)维护着一个命令历史栈这是实现强大撤销重做功能的基础。这种设计也使得宏录制、自动化脚本等功能更容易实现。3. 关键功能模块深度解析与实现3.1 文本格式管理与样式系统富文本的核心在于格式。我们实现了一个灵活且高效的样式系统。字符格式与段落格式分离格式被明确分为两类字符格式和段落格式。字符格式作用于选中的文本范围包括字体族、大小、粗体、斜体、颜色、背景色、下划线类型等。段落格式则作用于整个段落包括对齐方式左、中、右、两端、缩进左缩进、首行缩进、右缩进、行距以及段前段后间距。这种分离符合用户的直觉操作也便于内部管理。样式继承与覆盖机制为了减少冗余存储我们引入了“默认样式”和“样式覆盖”的概念。控件初始化时会加载一套默认的字符和段落样式。当用户对某段文本应用新格式时我们并不修改原始的字符运行而是创建一个新的字符运行它继承自原运行并覆盖指定的属性。这样即使频繁修改格式内存增长也是可控的。所有样式信息通过一个CTextFormat类进行管理该类使用LOGFONT和PARAFORMAT2等Windows原生结构并与GDI资源如HFONT进行高效转换和缓存。实操心得字体缓存优化频繁创建和销毁HFONT是GDI编程的性能杀手。我们建立了一个字体缓存字典以LOGFONT结构为键缓存在HFONT对象。当需要某种字体时先查缓存没有则创建并存入。控件销毁时统一释放所有缓存字体。这个简单的优化让文本渲染速度提升了近30%。3.2 嵌入式对象与OLE支持一个专业的富文本控件必须能处理图片、表格甚至其他应用程序的文档如Excel图表。我们通过OLE对象链接与嵌入技术实现了这一点。OLE对象的插入与激活当用户通过菜单插入一个OLE对象例如“插入-对象-Microsoft Excel图表”时控件会调用OleCreateFromFile或OleCreateNew等API在文档中创建一个“对象站点”。这个站点负责管理OLE对象的生命周期。在视图层对象被渲染为一个带有图标的占位框。双击该对象控件会调用OleActivate启动Excel并就地激活in-place activation该图表进行编辑此时控件的菜单和工具栏会与Excel的合并用户体验无缝。自定义嵌入式控件的实现除了标准的OLE对象我们还支持嵌入自定义的Windows控件比如一个日期选择器或一个按钮。这是通过实现一个特殊的“控件包装器”对象来完成的。该包装器在文档中作为一个特定类型的嵌入式对象存在在渲染时它会在指定位置创建并显示真正的Windows控件如CDateTimeCtrl。我们重写了控件的消息循环确保嵌入控件能正常接收键盘和鼠标消息。这在开发表单填写类应用时非常有用。3.3 撤销重做(Undo/Redo)引擎的实现撤销重做是编辑器的灵魂功能其实现质量直接关系到用户体验。基于命令模式的实现如前所述每一个修改文档的操作都被封装为一个命令对象继承自ICommand接口该接口通常包含Execute(),Unexecute()即撤销以及GetDescription()用于在历史列表中显示等方法。class ICommand { public: virtual ~ICommand() {} virtual BOOL Execute() 0; // 执行命令 virtual BOOL Unexecute() 0; // 撤销命令 virtual CString GetDescription() const 0; // 获取描述 }; class CInsertTextCommand : public ICommand { private: CString m_strText; CPos m_insertPos; CTextDocument* m_pDoc; public: CInsertTextCommand(CTextDocument* pDoc, const CPos pos, const CString text); virtual BOOL Execute() override { // 在m_insertPos处插入m_strText return m_pDoc-InsertText(m_insertPos, m_strText); } virtual BOOL Unexecute() override { // 从m_insertPos处删除长度为m_strText.GetLength()的文本 return m_pDoc-DeleteText(m_insertPos, m_strText.GetLength()); } virtual CString GetDescription() const override { return _T(插入文本); } };命令的合并与压缩如果用户连续输入字符每一个按键都生成一个CInsertTextCommand这会导致历史栈迅速膨胀且撤销时是一个字符一个字符地删除体验很差。我们实现了命令合并当新命令与栈顶命令是同一类型如连续插入且满足一定条件如插入位置相邻时将新命令合并到栈顶命令中。例如连续输入“hello”会合并成一个“插入hello”的命令而不是五个独立的命令。历史栈的管理与内存考量CCommandManager管理两个栈撤销栈(Undo Stack)和重做栈(Redo Stack)。执行新命令时将其压入撤销栈并清空重做栈。我们为历史栈设置了内存上限和步数上限。当超过限制时会丢弃最旧的命令。对于占用内存大的命令如插入大图片其内部会存储差异数据而非完整数据副本以节省内存。4. 控件集成与高级功能实战4.1 基础集成从零构建一个简单的文本编辑器让我们通过一个最简单的示例看看如何将这套控件集成到你的MFC对话框中。第一步将源代码加入工程将控件的所有.h和.cpp文件通常包括CRichTextCtrl.h/cpp,CTextDocument.h/cpp,CTextView.h/cpp等核心类添加到你的VC工程中。确保你的工程设置中#include路径能正确找到这些文件。第二步在对话框中放置控件在资源编辑器中为你想要放置富文本编辑器的对话框添加一个自定义控件(Custom Control)。设置其Class属性为“CRichTextCtrl”这是我们导出的窗口类名。并给它一个ID比如IDC_RICH_TEXT。第三步关联控件变量并进行初始化在对话框类的头文件中声明一个控件变量。注意我们使用DDX_Control进行动态绑定。// 在对话框类声明中 class CMyDialog : public CDialog { // ... private: CRichTextCtrl m_wndRichEdit; // 富文本控件对象 // ... };在CMyDialog::DoDataExchange函数中进行数据交换绑定void CMyDialog::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); DDX_Control(pDX, IDC_RICH_TEXT, m_wndRichEdit); // 关键绑定 }在CMyDialog::OnInitDialog()函数中我们可以对控件进行初始化比如设置默认字体、加载初始文本。BOOL CMyDialog::OnInitDialog() { CDialog::OnInitDialog(); // 设置默认字体 LOGFONT lf {0}; _tcscpy_s(lf.lfFaceName, _T(宋体)); lf.lfHeight -12; // 12像素高 m_wndRichEdit.SetDefaultFont(lf); // 加载一些带格式的文本 m_wndRichEdit.SetWindowText(_T(这是一个b加粗/b和colorFF0000红色/color的示例。)); // 注意实际API可能是SetText或LoadFromRTF这里为示意。 return TRUE; }第四步处理控件通知消息富文本控件在内容改变、选择改变时会向父窗口发送通知消息。我们需要在对话框的消息映射中处理它们。BEGIN_MESSAGE_MAP(CMyDialog, CDialog) ON_NOTIFY(RTN_TEXTCHANGED, IDC_RICH_TEXT, OnRichTextChanged) // 自定义通知码 ON_NOTIFY(RTN_SELCHANGE, IDC_RICH_TEXT, OnRichTextSelChange) END_MESSAGE_MAP() void CMyDialog::OnRichTextChanged(NMHDR* pNMHDR, LRESULT* pResult) { // 文本内容发生变化时的处理 UpdateData(FALSE); // 可能需要更新其他UI *pResult 0; } void CMyDialog::OnRichTextSelChange(NMHDR* pNMHDR, LRESULT* pResult) { // 选择区域发生变化更新格式工具栏状态 CHARFORMAT2 cf; m_wndRichEdit.GetSelectionCharFormat(cf); // 根据cf.dwMask和cf.dwEffects更新UI按钮加粗、斜体等的按下状态 *pResult 0; }至此一个具备基本编辑和格式显示功能的富文本编辑器就集成完毕了。你可以通过调用m_wndRichEdit的一系列成员函数如SetBold,SetFontName,InsertImage来实现更复杂的操作。4.2 高级功能实现打印与打印预览打印是桌面应用的重要功能。我们的控件内置了完善的打印和打印预览支持。分页计算与绘制打印的核心是将文档内容合理地分配到多页纸上。我们在CTextDocument中实现了一个CPaginator分页器类。它的工作流程如下获取打印机DC根据用户选择的打印机和纸张设置创建一个与打印机兼容的设备上下文(DC)。计算页边距和可打印区域考虑纸张大小、打印机物理边距和用户设定的页边距计算出每页实际可用于打印文本的矩形区域。遍历文档进行分页从文档开头开始模拟在打印DC上绘制每一行。使用GetTextExtentPoint32等GDI函数精确计算每行文本在打印分辨率下的高度。当累计高度超过当前页的可打印区域高度时就插入一个分页符并记录该页的起始段落和行号。这个过程会生成一个“分页信息”列表。生成打印预览打印预览的本质是在屏幕DC上按照缩放比例模拟绘制每一页的内容。我们创建一个内存位图按照屏幕DPI和缩放比例将一页的内容绘制到位图上然后显示出来。通过缓存已渲染的预览页位图可以快速响应用户的翻页操作。打印任务的执行当用户点击打印时我们启动一个打印任务调用StartDoc开始一个打印作业。遍历之前计算好的分页信息列表对每一页 a. 调用StartPage开始新的一页。 b. 将打印机DC传入控件的渲染层并告诉渲染器只绘制属于当前页的文档范围。 c. 调用EndPage结束本页。所有页绘制完成后调用EndDoc结束打印作业。注意事项打印机与屏幕的DPI差异这是打印中最容易出错的地方。屏幕DPI通常是96而打印机DPI可能是300、600甚至更高。所有涉及尺寸的计算字体大小、边距、图片缩放都必须基于当前DC的DPI进行转换。我们的做法是在分页和绘制时传入一个“缩放比例”因子这个因子是打印机DPI / 屏幕逻辑DPI。字体大小等逻辑单位需要乘以这个因子转换成物理单位例如12磅字体在300 DPI打印机上其lfHeight需要按比例计算。忽略这一点会导致打印出来的文字非常小或布局错乱。4.3 性能优化与大规模文本处理当文档内容达到数万行甚至更多时性能成为关键挑战。我们采用了以下策略虚拟化渲染与延迟加载对于超长文档一次性计算所有行的布局并渲染是不可行的。我们实现了类似列表控件虚拟化的技术。控件只计算和渲染当前可见区域及前后少量缓冲区域内的行。当用户滚动时动态计算新进入视图的行并渲染。对于嵌入式的大图片或OLE对象采用缩略图先行加载完整内容按需加载的策略。增量式布局计算文档的布局计算确定每行宽度、高度、换行位置是CPU密集型操作。我们将其设计为增量式。当文档某处被修改如插入文本我们只重新计算从修改点开始到受影响的段落结束范围内的布局而不是整个文档。这需要维护一个段落之间的依赖关系但能极大提升编辑响应速度。高效的屏幕刷新我们重写了控件的OnPaint处理采用“脏矩形”技术。只对需要更新的区域如光标闪烁的位置、文本选择变化的区域进行重绘避免全屏刷新带来的闪烁和性能损耗。同时对于连续的快速操作如按住退格键删除进行绘制操作的合并与节流避免UI线程被拖垮。5. 常见问题排查与调试技巧实录在实际使用和集成这套控件的过程中你可能会遇到一些典型问题。以下是我总结的“避坑指南”。5.1 内存泄漏与资源管理在GDI编程中资源泄漏如HFONT,HBITMAP,HPEN是常见问题会导致程序运行一段时间后GDI对象耗尽界面异常。问题现象程序运行一段时间后界面绘制变慢、残缺甚至整个窗口变白。在任务管理器中查看进程的GDI对象数量持续增长。排查与解决使用工具利用Visual Studio的诊断工具或专门的GDI泄漏检测工具如GDIView来监控进程的GDI对象句柄数量。遵循“谁创建谁销毁”原则确保每一个CreateFont,CreateBitmap,CreatePen等调用都有对应的DeleteObject。最好将GDI资源封装在C类中利用RAII资源获取即初始化机制在析构函数中自动释放。检查缓存机制我们实现的字体缓存等机制必须在控件销毁时如WM_DESTROY消息中确保清空缓存并释放所有缓存的GDI对象。一个常见的错误是只清空了缓存的数据结构忘了释放实际的HFONT。OLE对象泄漏嵌入式OLE对象如果未正确释放会导致更严重的内存泄漏。确保在文档清除或控件销毁时遍历所有嵌入式对象站点并调用OleSetContainedObject和Release。5.2 光标闪烁与绘制异常问题现象光标不闪烁、闪烁频率异常或者在滚动、缩放后光标位置显示错误。排查与解决光标定时器光标闪烁是通过一个Windows定时器(SetTimer)实现的。确保在控件获得焦点时启动定时器(KillTimer)失去焦点时销毁定时器。定时器消息处理函数中应反转光标所在位置的绘制通过异或操作并强制重绘光标矩形区域。光标位置计算光标的位置行、列必须根据当前文档布局、滚动偏移和缩放比例精确计算为屏幕坐标。任何影响布局的操作如插入删除文本、改变窗口大小、缩放后都必须重新计算并更新光标位置。调试时可以输出光标逻辑位置和计算后的屏幕坐标进行比对。双缓冲与绘制顺序如果使用了双缓冲技术来消除闪烁要确保光标是在最后一步绘制到屏幕DC上的否则它可能会被背景覆盖。通常的绘制顺序是先将所有文本和背景绘制到内存位图然后将内存位图拷贝到屏幕DC最后在屏幕DC上绘制光标。5.3 复制粘贴格式丢失问题现象从控件中复制带格式的文本到Word或记事本格式丢失或者从网页复制内容到控件格式混乱。排查与解决剪贴板格式支持富文本控件应同时向剪贴板注册多种格式包括纯文本(CF_TEXT)、富文本(CF_RTF)、HTML(CF_HTML)等。在Copy操作中将当前选中的内容以这些格式分别准备好。在Paste操作中按格式的“丰富程度”优先级如CF_HTMLCF_RTFCF_TEXT从剪贴板获取数据并解析。RTF格式处理RTF是一种复杂的格式描述语言。我们使用了微软提供的RichEdit流输入输出函数如StreamIn,StreamOut来简化RTF的序列化与反序列化。确保在复制时正确调用StreamOut生成RTF字节流在粘贴时调用StreamIn解析RTF流。注意处理字符编码ANSI/Unicode问题。HTML粘贴过滤从网页粘贴的HTML通常包含大量样式和标签。直接全部解析并渲染会非常复杂且可能引入不安全脚本。一个实用的策略是进行过滤只解析和支持一部分安全的、基本的HTML标签和CSS样式如b,i,font color...,p align...忽略其他复杂标签。可以集成一个轻量级的HTML解析库如libxml2的HTML解析模块来辅助这个过程。5.4 与高DPI显示器的兼容性问题问题现象在4K等高DPI屏幕上控件显示模糊或者字体、布局大小异常。排查与解决启用DPI感知在应用程序清单文件(.manifest)中声明DPI感知。对于VC程序通常需要设置为dpiAwareTrue/PM/dpiAware或dpiAwarenessPerMonitorV2/dpiAwareness。这样系统会告知程序真实的DPI值。使用物理像素和逻辑坐标转换所有内部的坐标计算和GDI绘制应基于逻辑坐标。但在获取屏幕尺寸、窗口大小时需要与物理像素进行转换。使用GetDeviceCaps(hdc, LOGPIXELSX)获取DPI并使用MulDiv等函数进行缩放计算。我们的控件在初始化时会查询主屏幕的DPI缩放比例并以此为基础调整默认字体大小、图标尺寸等。资源图像多版本工具栏图标等位图资源应准备多个分辨率版本如16x16, 32x32, 64x64并在运行时根据当前DPI缩放比例加载合适的版本避免拉伸导致的模糊。这套源代码和示例是我多年桌面开发经验的结晶。它可能不像最新前端框架那样光鲜但其稳定、高效和深度可控的特性在需要复杂文档处理、专业排版或与硬件紧密集成的工业级Windows桌面应用中依然有着不可替代的价值。代码中充满了各种针对特定场景的优化和妥协这些“雕琢”的痕迹正是其区别于通用组件的魅力所在。如果你正在面临类似的开发挑战希望这份“遗产”能为你提供一个坚实可靠的起点。
