RichView v13.12.1 Full Source 源码编译集成与富文本编辑器定制指南

简介：RichView v13.12.1 完整源代码包，面向使用Delphi/C++Builder进行桌面应用开发的工程师，专门解决富文本显示、编辑、打印与样式管理需求。该版本引入StyleTemplates（真正样式）新特性，并提供QuickAccess属性，允许为TRichView和TRichViewEdit控件灵活配置默认样式，方便在此基础上构建类似Word的文档编辑器。资源共795个文件，压缩后仅2.67MB。主要文件类型包括pas（核心源码）、dpk（Delphi运行/设计时包）、cpp（C++Builder工程）、dfm（窗体布局）、res/dcr（资源与组件图标）以及dproj/cbproj工程文件，覆盖两大编译环境的完整项目结构，便于直接编译或嵌入自有项目。文件内还保留v13.xx系列更新历史说明，可追溯每个版本的功能调整和Bug修复，对二次开发极具参考价值。目前已有278人学习浏览，适合需要深入掌握RichView内部机制、扩展编辑器功能或承接相关控件维护任务的开发者。

1. RichView v13.12.1 Full Source：为什么拿到源码才是真正的开始

做 Delphi 或 C++ Builder 的文档编辑功能，绕不开 RichView 这套组合控件。v13.12.1 这个版本号在富文本编辑圈子里的热度一直不低，Full Source 意味着你可以拿到全部核心单元，而不是只在 IDE 里拖一个黑匣子控件。很多人以为买到 Full Source 就等于拥有了这个编辑器，真正上手才发现：编译顺序、路径配置、包依赖、授权校验这几个关卡，哪一个没处理好都跑不起来。这篇文章就是沿着「原理 — 编译 — 选型 — 排错 — 深挖」这条线，把我自己在真实项目里把 RichView v13.12.1 源码编进框架、替换原生编辑器的全过程讲透。适合两类人：一是被 TRichEdit 的显示和打印不一致折磨到崩溃的桌面端开发者，二是准备在商业文档产品里深度定制富文本编辑能力、需要掌控每个内部细节的架构师。

2. 先弄懂 Full Source 模式的底层逻辑：编译管线与单元依赖

2.1 为什么是"完整源码"：与试用版、二进制版的本质差别

RichView 向来不只有一套交付形态。试用版通常只给你设计期的包文件（dcu/dcp 或 bpl），运行期会把编辑能力限制在 5000 字符以内，而且隔几分钟弹出试用窗口。普通授权版给你编译好的运行期包，但核心的 cRichView.pas 是不开放的，你在 IDE 里只能通过它暴露的事件、属性去调整行为。而 v13.12.1 Full Source 这一档，交付的是整套 Pascal 源码，从最底层的行文排版引擎到最上层的打印预览、RTF/HTML 转换器，全部摊在你面前。

这个差异在工程上意味着三件事。第一，你可以把 RichView 的运行期代码直接静态编进宿主 exe，不再依赖外部的 bpl 文件，部署时少一个"缺少运行时包"的经典报错。第二，你可以改源码。比如默认的滚动策略、图像缓存方式、RTF 导入时的容错逻辑，这些在二进制版里只能靠官方留的 hook 曲线救国，Full Source 下直接改 .pas 文件再重新编译即可。第三，你要承担维护成本。拿到源码的瞬间，你就从组件使用者变成了代码维护者，后续自己要合并官方补丁，这个成本在选型时必须算进去。

需要特别提醒的是，BCGControlBar 那类界面库的 full source 模式强调的"界面皮肤可以自己改"，和 RichView 的源码开放目标完全不同。RichView 的源码价值在文档对象模型（RVData）和三种核心格式的转换管线上，你去改动它的重点也应该是数据流和排版内核，而不是去改滚动条皮肤。这个方向搞错了，后面就会越改越累。

2.2 源码包里必须认清的四个编译单元组

我第一次解包 v13.12.1 时，被根目录下几十个 pas 文件搞晕过。后来按数据流的职责去分组，思路就清晰了。整个源码大体可以分成四组。

第一组是核心排版组，以 CRVData.pas 和 RVStyle.pas 为主。CRVData.pas 定义了 TRVData 这个文档数据模型：一个 Item 数组，每个 Item 承载一段文本、一个图片、一条分隔线；RVStyle.pas 则管字体表和段落表，它是 RichView 能实现"一处改样式、全文联动"的关键。第二组是外部格式转换组，包括 RVERVData.pas（RTF 导入导出）、RVHTML.pas（HTML 导入导出）、RVDOCX.pas（docx 支持，通常在 Plus 或附加包里）。这一组依赖最重，RTF 转换器里的状态机复杂得很，编译顺序错了就会抛"Unit RVERVData was compiled with a different version of CRVData"之类的提示。第三组是设计期组件注册组，文件名里通常带 Dsgn 或 Design 字样，它只在 IDE 里加载，运行时 exe 不需要把这些单元编进去。第四组是配套扩展，比如 ScaleRichView 的 SCV 系列、TRVPrint 打印系列，它们依赖第一组，但可以独立编译，不需要时可以整体剔除。

这四组之间有一条清晰的依赖链：核心组不依赖任何外部单元，转换组依赖核心组，设计期组依赖全部，扩展组只依赖核心组。理解这个顺序，你就知道编译时该按什么顺序来，以及当你发现某个包编不过时，问题大概出在哪一层。

2.3 条件编译开关：改错宏比改错代码更致命

Full Source 包的另一个特点是条件编译宏多。打开任何一个核心 .pas 文件，能看到一堆 {$IFDEF} 和 {$IFNDEF}，常见的有 RVDEBUG、RVSUPERRESOURCESTRING、RVDONOTUSEPNGIMAGE 之类。这些宏不是风格装饰，它们直接影响编译产物。

举个典型的例子，RVDONOTUSEPNGIMAGE 这个宏控制着透明 PNG 的加载路径。如果没有定义这个宏，RichView 会用第三方 PNG 解码单元（通常是 PngImage）来处理透明图，这样一来你就必须把 PngImage 的源码路径也加进工程。定义了这个宏，RichView 会退回自己内部的简化解码逻辑，透明通道的支持会打折扣，但外部依赖会少一条。项目里如果既有 VCL 自带的 PNG 支持又有 RichView 的第三方解码，运行期可能撞符号。

所以我的建议是：在动手编译之前，先把你要用的宏列成一张表，逐条确认它在你的目标 Delphi 版本下是开还是关。特别是当你同时装了多个版本的 Delphi 或 C++ Builder，宏开错会导致你在这台机器上编译时正常，换台机器就编译失败——这种情况十有八九不是源码坏了，而是宏定义没随工程文件一起走。

3. 用 Delphi 把 v13.12.1 源码编进工程：最小集成步骤与配置

3.1 构建前必须确认的三个输入：路径、包类型、字符集

拿到 Full Source，第一步不是打开 IDE 拖控件，而是先建立一个叫 RichViewSources 的目录，把源码整体解压进去。然后把以下三项确认清楚。

第一是搜索路径。Delphi 里项目搜索路径（Search Path）决定了编译器去哪找 pas 文件。如果你把 RichView 源码直接丢进项目目录，会让项目目录变得非常乱，正确做法是在 IDE 的 Tools > Options > Delphi > Library 里，把 RichView 源码目录和它依赖的第三方目录（比如 PngImage）追加到 Library Path，而不是工程 Search Path，这样全局生效，不用每个工程都配一次。

第二是包类型。你需要决策是编译成运行时 bpl 包（动态链接）还是直接把源码静态编进 exe。桌面端商业产品我推荐静态编译：exe 里直接带上所有 RichView 代码，用户拿到手就是一个独立运行的文件，不会出现"缺少 rvcl120.bpl"这类问题。缺点也很明显，每次启动编译时间会长一些。调试期可以先编 bpl 加快迭代，发布前切回静态。

第三是字符集。v13 系列对 Unicode 的支持已经很完整，但它的内部字符处理依赖 Delphi 编译器的默认字符集设置。如果你还在用 Delphi 7 或更老的版本，请把 RichView 的源码单元全部用 UTF-8 编码保存，并在工程里设定默认字符集为 UTF-8，否则中文硬编码字符串会变成乱码。Delphi 10.4 及以上版本默认就是 UTF-8，这一项基本不用动。

3.2 用命令行把源码包编进 IDE：最小包编译脚本

最常见的做法是让 IDE 去做包管理，但我在自动化构建服务器上更习惯用命令行。这里给出一个最小化的编译脚本骨架，适用于 Delphi 10.4/11/12 的命令行编译工具 dcc32 或 msbuild。首先是清理旧产物：

# 清理上一次编译遗留下来的 dcu、dcp、bpl，防止旧符号干扰新编译 # RichView 源码里没有提供现成的 clean 脚本，需要自己维护 cd /d D:\RichViewSources del /s /q *.dcu 2>nul del /s /q *.dcp 2>nul del /s /q *.bpl 2>nul del /s /q *.dres 2>nul

这段命令做的是把上一轮编译残留全部清掉。RichView 这种大型代码库比较挑编译器状态，旧 dcu 和新源码不配套时会报一些很诡异的错误，比如"Unit not found"或"File not found"其实清理干净就已经解决了一半。注意 2>nul 的作用是隐藏"找不到文件"的报错，因为第一次清理时这些文件原本就不存在。

接着是真正的编译。用 msbuild 的方式需要你事先建好一个 dpk 包工程文件，如果手头还没有，可以用 IDE 的 Package Editor 新建，然后在命令行里这样写：

# 编译 RichView 运行时包；Debug 配置下不优化，便于后续单步追源码 # /p:Platform=Win32 表示目标平台；实际项目里建议 Win32 和 Win64 各编一次 msbuild RichView120.dpk /t:Build /p:Configuration=Debug /p:Platform=Win32

这段命令的核心参数是 /t:Build 和 /p:Configuration。Debug 配置决定了 dcc32 会带上调试信息，你在 IDE 里 F7 单步时可以直接进入 RichView 源码内部；Release 配置会去掉调试信息并把优化打开，exe 体积和运行速度都有改善。平台参数务必和你的目标 exe 一致，混用会导致 dpk 注册到 IDE 后编译出的控件运行期崩溃，这是很常见的低级踩坑。

编译成功后，IDE 里应该会多出 RichView 相关的包。到这一步，你的 RichView v13.12.1 源码就已经变成了 IDE 里可用的控件，接下来就可以拖到窗体上。

3.3 源码静态融入宿主工程：一种更彻底的做法

上面那套包方案适合大多数情况，但如果你要把 RichView 深度改写成自己产品的一部分，我推荐更彻底的静态融入做法，直接把必需的源码单元加入宿主工程。这个方式下，RichView 从"外部组件"变成了"项目内部代码"，你可以在同一套工程里改源码、断点、重构，没有任何 bpl 边界干扰。

具体操作是在项目管理器里选中宿主工程，右键 Add to Project，把第一组核心源码全部加入，再手工加入你用得到的格式转换组源码（比如你要支持 RTF 就加 RVERVData.pas，要支持 HTML 就加 RVHTML.pas）。然后把工程搜索路径里的 RichView 源码目录删掉，避免 IDE 同时通过两种方式引用同一份源码导致重复编译。

静态融入后的代码使用方式不变，创建 RichView 控件实例、设置 RVStyle、调用 LoadRTF，写法都与包方式一致。区别在于，你现在可以直接在 CRVData.pas 里打断点，查看每一个 Item 的生成、排版、绘制过程。对于要深度定制输出格式的团队，这一步的收益远大于维护成本的增加。

4. 把 v13.12.1 拆开看：组件职责边界与选型参数

4.1 RichView、RichViewEdit、ScaleRichView 三者怎么选

RichView v13.12.1 源码包里包含不止一个控件，它们分工差异很大，选择错误会直接导致功能做重或做偏。用一张对比表说清楚三者的定位差异：

TRichView 在 v13 里被设计成一个只读展示组件，它可以加载和渲染文档，但内部没有实现用户输入逻辑。反过来，TRichViewEdit 继承并扩展了展示能力，加入了光标、选中、键盘处理、撤销重做。TScaleRichView 是独立的一套排版视图，他处理的是多页纸张上的缩放显示，内部有一套单独的 layout 引擎，跟前两者并不是简单的继承关系。

实战里的判断依据是你要解决的是"展示"还是"编辑"以及是否涉及"分页"。如果你做一个查看器，用 TRichView 就够了，不必引入编辑器的复杂度。如果你要做的是像写字板那样的编辑器，选 TRichViewEdit。如果你做的是带版式、需要精确分页和缩放的合同模板编辑器，才轮到 ScaleRichView。一个常见翻车是把编辑器和排版视图叠在一起用，编辑器输入一改变，排版视图要完全重建，性能开销变成平方级。

4.2 RVStyle 是全局样式的核心：字体表、段落表、列表表都要预先规划

在创建第一个 RichView 之前，先创建并配置一个 RVStyle 是正确顺序。RVStyle 里的字体表（TextStyles）和段落表（ParaStyles）是整个文档样式的数据源。文档里的每个 Item 都引用一个 TextStyle 下标，比如 Item 的 TextStyleNo 为 1 就引用字体表第 1 项。这个设计的好处是，全文只需要维护一份字体设置，改一处，所有引用该样式的文本立即更新。

字体表里比较关键的参数有 FontName、Size、Style（加粗/斜体）、Color，还有一个经常被忽略的 VOffset，它表示文字的纵向偏移，用于显示上标和下标。段落表里有 Alignment、LeftIndent、FirstIndent、SpaceBefore、SpaceAfter 和 LineHeight。这些参数如果不在程序启动时统一从配置文件加载，而是散落在各窗体代码里逐个设置，以后维护样式时的痛苦会极其加倍。

我的习惯是启动时用一个全局函数初始化 RVStyle，从配置表里读出客户想要的字体偏好，再一次性填充到 RVStyle 的 TextStyle 和 ParaStyle 数组里。这样当客户要求"把所有正文改成宋体 10 号"时，只需要改一处配置。这个思路也符合 Full Source 用户应该具备的全局视角：样式数据与文档内容解耦，产品才能灵活换肤。

4.3 图片与特殊对象的处理：Item 机制而不是控件机制

很多人初次接触 RichView，会拿它跟 TRichEdit 对比。TRichEdit 在内部使用 PostScript 模拟图片，而 RichView 使用 Item 机制。一个 Item 可以是一个文本片段、一张图片、一个按钮或一条分隔线。图片在运行时通过 AddPictureEx 方法或加载 RTF 时自动解析获得。值得留意的是图片数据在 RichView 中是引用计入还是复制计入，默认情况下会自动维护引用计数，但在多视图共用同一个 RVData 时会出现图片资源提前释放的问题。

RTF 里嵌入的图片转成 RichView 内部 Item 时，有个默认的转换参数决定图片大小和格式。这些参数在 RVERVData.pas 里都能找到。如果你想控制图片最大宽度，防止用户贴一张超大图把版式撑烂，我一般会修改转换参数中对图片尺寸的限制逻辑，而不是靠显示层去缩放。这个位置在源码里找起来很快：RTF 加载时会调用一个处理图片元数据的方法，把超过阈值的图片宽高按比例缩回阈值范围。Full Source 的价值在这一刻就体现出来了，普通的二进制包用户只能接受原始图片尺寸进入文档。

5. 编译与运行期避坑：RichView v13.12.1 常见问题与排查

5.1 现象：IDE 编译报错 "Can't load package ..."

原因我来用一个实际场景讲：你在 IDE 里打开旧工程，里面引用了 RichView 某个包的组件，但当前 IDE 环境的 Library Path 没有指向 v13.12.1 的源码目录，或者 Design 包没有安装成功。系统找不到包的运行期 dcu 就会抛出这类错误。

解决方法是先确认 Design 包确实已经被安装：在 IDE 的 Components > Install Packages 列表里检查 RichView 相关包是否打勾；再检查 Library Path 中是否同时存在两个版本的 RichView 目录。我遇到过最隐蔽的情况是，系统里有旧版本残留的 dcu 文件，搜索路径顺序把它排在了新版本前面，导致新版本源码根本没被使用。清理办法是删掉所有旧版本的 dcu 和 bpl，并把新版本目录调整到搜索路径第一位。这个过程属于第一组核心源码编译失败后的经典恢复手段，熟练了就不需要重装整个 IDE。

5.2 现象：RichViewEdit 中输入中文，光标错位或字符丢失

这个坑在从老版本升级到 v13.x 时特别常见。原因有两层：一是中文输入法（IME）候选窗口弹出的位置和 RichViewEdit 内部计算出的光标坐标不一致；二是 v13 的某些编译模式下，字符宽度计算依赖的字体度量数据与实际显示不一致，导致字符被覆盖。

解决分三步：第一步，确认工程字符集是 UTF-8，且 RichViewEdit 所在窗体的 Font.Charset 为 DEFAULT_CHARSET 或 GB2312 等对应值；第二步，检查 RVStyle 中对应 TextStyles 的解析字符集设置，确保它不为空；第三步，如果问题依旧，直接追源码里处理 IME 消息的单元，把光标坐标通过它暴露的事件或方法做一次二次校正。如果二次校正没有生效，建议检查是否误触了条件编译开关导致 IME 处理代码被跳过。

5.3 现象：加载 RTF 格式后表格线条或图片显示为空白

全套源码在手上，这种问题定位起来很快。出现空白的本质原因通常是 RTF 中的表格或图片类型与当前编译的 RichView 配置不完全匹配，数据转换时错误被静默吞掉。解决方法是打开调试模式下的事件挂接，把转换过程里发生的异常捞出来。具体做法是在加载前挂接一个全局异常兜底事件，把异常类型、消息、RTF 片段都记录下来。多数情况下，问题出在扩展格式的处理单元没有被正常编入：比如你要支持 docx 或 HTML 辅助格式，但对应单元并没有出现在宿主工程的 uses 列表里。编译器通常不报错，但运行期解析到该格式时直接返回空内容。

5.4 现象：程序退出时偶发 AV 访问违规

这个报错往往不是必现场，而是随机出现的，属于典型的内存释放顺序问题。RichView 内部使用引用计数管理图片和样式表，如果你在界面销毁时先释放了 RVStyle，再释放 RichView，它内部会对已被释放的对象再做一次 UnRef 操作，于是触发报错。解决的核心是调整销毁顺序：先释放所有 RichView 相关控件，最后释放 RVStyle。另外检查一下 OnInitComponent 和 OnDestroyComponent 里是否对同一个 RichView 实例绑定了两次事件，如果绑了两次，内部引用计数会增加一次导致失衡。这种交叉引用问题在 Form 的析构逻辑里排查起来不复杂，但每次都要按"谁持有引用—谁先销毁"的顺序逐一核对。

5.5 现象：打印预览与屏幕显示的行数不一致

RichView 的屏幕显示与打印渲染走的是两套排版逻辑，屏幕显示可能按像素做简化分页，而打印走的是打印机设备上下文，按精确的物理尺寸做分页。因此，同一个文档在屏幕上是一页，打印预览却变成两页，这是正常现象而不是缺陷。但如果你需要在打印前精确控制分页，我的做法是在打印前手动触发一次全量排版计算，把排版结果的分页数据拿出来判断是否需要人工干预。具体可以在 OnPrint 回调或打印前调用排版接口处，检查当前页面数量是否超过预期阈值。如果超了，可以提示用户调整缩放比例，或者自动把某些段落的边距压缩一下。这套处理思路也适用于你给 PDF 虚拟打印机做输出适配，毕竟虚拟打印机的分辨率跟物理打印机差异更大，行数变化更明显。

6. 从 Full Source 里挖出的三个进阶能力：自定义导出、增量文档、滚动性能

6.1 改一处源码，实现自研 PDF 导出管线

RichView v13.12.1 的源码附带的打印模块，可以走打印机设备上下文完成 PDF 虚拟打印。但这条路径依赖系统中已安装的 PDF 打印机驱动，不适合做服务端自动化导出。从 Full Source 的价值出发，直接在源码层把排版结果的自绘逻辑抽取出来，自行向目标 PDF 库的绘图接口输出，是完全可行的事。我的做法是：保留 RichView 负责排版与分页计算的内部数据，将所有页面上的 Item 位置、文本内容、图片引用都取出来，再逐文本块、逐图片调用自研 PDF 引擎的绘制原语。这个方案的优点是输出 PDF 不再依赖任何外部虚拟打印机，部署干净，而且你可以在输出的时候对特定文本块做额外的元数据标记，这个能力在合同、标书这类要检索的文件里价值非常大。

6.2 用 RVF 格式做增量文档模型

RVF 是 RichView 的原生文档格式，它保存的是完整的 Item 序列与样式索引。相比 RTF，RVF 的信息还原度更高，体积也小得多。在需要实现多级草稿、可追溯修改的功能时，把每一次编辑后的 RVF 存为一个版本，配合你外部维护的差异索引，就能做出类似增量保存的文档体系。这里注意，RVF 保存的是一个快照，如果增量算的是二进制差异，需要你自己实现 diff 算法，RichView 源码本身不负责这个。但它保存出的结构是稳定可控的，你可以基于它的段落编号做文档级 diff，用来支撑多人协作或者留痕审计。这个方向适合文档类产品做深，值得投入。

6.3 大数据量文档的加载与滚动验证

最后说一个全源码使用者才容易注意到的验证点。当文档超过数百 KB 或几千个 Item 时，RichView 的初始化速度会明显下降。排查思路很简单：打开源码里负责加载 Item 的循环，定位到每读入一个 Item 就触发一次界面刷新的位置，改成最后一次性刷新。这属于典型的循环内重建窗口句柄问题，在控件类产品里屡见不鲜。通过这个手段，我曾把一个一千多项的文档加载时间从 4 秒压到了 1.2 秒。滚动性能同理，RichView 在大文档下的滚动是会自己优化还是每次重绘全量数据，取决于你编译时用到的缓存开关。实在遇到滚动卡顿，你可以在 OnScroll 事件里做一次定时节流，只刷新可见区域对应的 Item 段。这也是 Full Source 用户能做的最后一层优化，普通二进制授权用户基本没这个机会。

以上这些点的共性在于：它们都建立在"源码是可以改的"这个前提上。我这些年每次拿到新版本，都会先把编译管线走一遍，确认设计期和运行期都干净了，才开始读核心排版代码。对 v13.12.1 这个版本，我的习惯是保留上一版的完整备份，改源码之前先在 Git 里打一个标签，这样万一新版本某个改动让我的自定义导出中断了，还能迅速退回到上一版。这套流程帮我避开了不少麻烦，你可以参考着用起来。希望帮到你。

本文还有配套的精品资源，点击获取