简介针对Delphi XE7与Lazarus开发者的富文本编辑控件资源包集中提供TRichView 23.1版本的集成组件与配套资料适用于需要在Windows或跨平台环境中处理复杂文档界面、实现格式化文本、图片、表格及超链接展示的应用场景。压缩包共2000个文件以1612个cpp源码和349个h头文件为主便于二次定制或深度集成另含36个txt说明、2个pdf文档和1个htm示例涵盖使用指引与参考样例整体体积仅26.85MB结构紧凑。当前已有133人学习使用属于轻量但功能完整的控件开发套件。内容包含可直接调用的组件源码、编译配置参考以及演示工程可帮助开发者快速在Delphi或Lazarus中搭建富文本编辑器并利用RTF、HTML、Markdown等多格式渲染能力增强应用交互体验。对于希望复用成熟文本控件、减少底层排版开发投入的中高级Delphi程序员是一份值得收藏的实用资源。1. TRichView-23.1安装包一个压缩包如何覆盖Delphi XE7到12.3与Lazarus如果你手上正好有一个名为TRichView-23.1-XE7-D12 Lazarus.7z的压缩包大概率正被富文本编辑、文档预览或报告生成这类需求找上门。这个包的核心是Delphi生态里历史很长的富文本控件TRichView而真正值钱的是包名里那串版本号XE7-D12和Lazarus意味着一份源码能同时适配从Delphi XE7到Delphi 12.3的多个主要版本还附带Free Pascal系的Lazarus IDE支持。以前那种升级Delphi就担心控件编译不过、换平台就得另找方案的麻烦用它能省掉一大半。对正在维护老项目又想迁移到新IDE的团队或者要在Windows和Linux下出同一套界面的开发者下面这些内容是我按自己的安装顺序整理的完整路径覆盖解压、Library path配置、dpk和lpk的编译安装以及我在两个IDE里反复遇到的坑。2. 为什么富文本编辑器要选TRichView从原理看控件选型2.1 富文本编辑的技术路线TRichView与Memo、RichEdit的边界Delphi自带的TMemo就是一个纯文本编辑组件它能处理多行文本、选择和复制粘贴但无法在同一行里让一部分字是红色粗体、另一部分是蓝色斜体更塞不进图片和表格。原生RichEdit控件读得了RTF排版引擎却是操作系统内部实现的不同Windows版本上的渲染细节存在差异到了Linux或macOS上根本没有对应的原生控件可以用。TRichView走的是自绘路线整个编辑区由控件自己绘制不依赖系统提供的RichTextBox。它内部维护一棵文档对象树文档是根节点往下是段落节点段落包含若干run节点run是最小格式单元即一段颜色、字体、字号都相同的连续文字。图片、表格、分隔线等特殊对象也以节点形式挂在树上。这种模型和浏览器的DOM思想类似带来两个直接好处。第一对文档的插入、删除、替换都可以通过操作节点完成不需要每次把整个文档转成字符串再拼回去操作大文档时性能可控。第二格式的查询和修改可以精确到run粒度想实现“把光标所在单词设为高亮”这类需求只需定位到包含光标的run节点并改它的颜色属性。自绘的代价是控件要自己处理光标闪烁、选区反色、字体回退、换行计算这些排版细节工程量很大。TRichView把这些都封装好了使用者的日常工作被简化成往文档里加内容、设定样式、调用格式化方法。它内部根据文档树和样式属性计算出每个run的显示位置再完成绘制。相比RichEdit的黑匣子行为TRichView的排版逻辑在多种平台上保持一致这是它适合做跨平台桌面项目的底层原因。实际工程里一个包含几十页图文混排的文档在TRichViewEdit里滚动和重绘都足够跟手换成RichEdit或Memo很难达到同样效果。2.2 TRichView组件家族与数据模型TRichView不是一个单控件而是一整套配合工作的类。最核心的两个是TRichViewEdit和TRichView。TRichViewEdit提供完整的编辑交互包括光标移动、文本选择、撤销重做、拖放适合做数据录入或内容编辑界面。TRichView偏只读展示适合把数据库里的RTF文案渲染成预览效果它的OnHyperlink等事件可以让只读文档实现可点击链接的效果。这两个核心控件共享同一套文档模型所以在运行时可以把TRichViewEdit的Document直接赋给TRichView的Document实现编辑态与预览态的快速切换不用先把内容序列化成文件再读回。外围配套组件按职责分了几类。TRVStyle负责全局样式把默认字体、字号、颜色、间距集中管理控件通过Style属性引用它。读写器按格式拆成TRVRTFReader、TRVRTFWriter、TRVHTMLReader、TRVHTMLWriter专门处理RTF和HTML的导入导出。这些字符器不依赖编辑器界面是纯对象可以在后台线程里把一段RTF字节流转成文档树再交给界面层渲染。这种边界清晰的设计让接入新格式时不用改动编辑器核心代码只要写一个新的Reader/Writer组件。序列化和克隆的边界也值得留意。TRichViewEdit的Undo/Redo栈里保存的是操作记录而非常量快照内部通过保存操作前后的节点引用来实现撤销。在实际项目里如果需要在多个文档之间复制复杂内容含图片和表格的段落建议用文档对象级别的插入接口从一个文档对象往另一个文档对象插入节点子集避免先导出后导入时格式丢失。TRichView对节点归属管理得比较严格节点不能同时属于两个文档复制时应当用专门的插入接口而不是直接移动节点。2.3 选型理由跨版本与跨平台支持为什么关键很多Delphi控件是跟着IDE版本走的。新Delphi一出老版本包就编译不过团队只能等厂商更新或者被困在旧IDE上。TRichView的做法不同它的源码通过条件编译自适应多个Delphi版本包名里的XE7-D12就是这套能力的直接体现。升级IDE时把Source目录指到新版本的Library path里重新编译一遍运行时包项目就能继续沿用同一套控件接口。Lazarus支持的意义在于平台。Delphi的Windows版应用没法直接编译成Linux原生程序但Lazarus配合Free Pascal可以。TRichView的同一份源代码在Lazarus下能编译成Windows、Linux、macOS的原生GUI程序这对要交付桌面客户端到内网Linux服务器或国产操作系统环境的项目有实际价值。我做过的报表预览客户端就是在Windows上开发调试用Lazarus重新编译后部署到Linux工控机界面和交互逻辑几乎没改。选型还需要考虑分发形式。TRichView以源码包形式分发里面同时带Delphi的dpk工程文件和Lazarus的lpk工程文件。这意味着安装不是“放个DLL进去就行”而是要在IDE里配置源码路径、按顺序编译运行包和设计包。好处是你能看到并修改控件代码遇到bug可以自己定位坏处是安装门槛比单文件控件高。这正是本篇要解决的问题把源码包正确改装成两个IDE里可用的组件。拿到压缩包后还应该先看Docs目录下的License文档确认项目属于商业还是非商业场景免得在授权上踩雷。3. 在Delphi 12.3里安装TRichView从解压到编译安装全流程3.1 解压结构与目录规划7z格式用7-Zip解压即可。解压前先建一个干净目录常见做法是建在D盘或数据盘根目录下直接用版本号命名如D:\Components\TRichView-23.1。解压完成后先别急着开IDE先看目录结构。一般会有Docs目录放官方文档和安装说明Source目录放单元源码和.inc条件编译文件Lib目录放按Delphi版本和平台组织的预编译dcuDemo目录里有很多示例工程。有些版本还会在packages目录下按Delphi版本分子目录把dpk文件按版本归类。打开Docs里的安装说明找到对应Delphi版本的章节它会告诉你完整的编译顺序和依赖项。不要跳过这一步因为TRichView在不同大版本间的主目录结构可能不同。如果说明里给出了推荐的Library path就按那个来不要图省事只加一个目录就往下走。一个反复踩到的坑是路径中的空格和中文。把包解压到C:\Program Files这类带空格路径下虽然大多数时候IDE能处理但TRichView的某些构建脚本和Demo工程里写的相对路径在遇到空格时解析不对。我见过有同行把包解压到“项目文件2024”这样带中文的目录里之后编译Demo时总报找不到文件查了很久才发现是路径里的中文在某个老工程文件里没有被正确处理。这里建议直接用纯英文、无空格的短路径能少一个隐患。提示路径里避免空格和中文。这类源码包的构建脚本常以空格作为分隔符解析路径一旦路径带空格一段完整路径可能被拆成两段会出现莫名其妙的“找不到文件”报错。3.2 配置Delphi 12.3的Library路径打开Delphi 12.3进入Tools Options Language Delphi Library。页面上有Library path配置并且会分平台32-bit Windows和64-bit Windows各一行两行都要把Source目录加进去。这个路径是全局的不依赖某个工程文件。加入Source目录时要注意顺序。Delphi搜索单元的顺序是工程文件目录、工程搜索路径、Library pathLibrary path里靠前目录的优先级更高。如果机器上装过旧版本TRichView旧Source目录或Lib目录残留在Library path里重新编译时容易产生新源码配旧dcu的混用问题。一个更可靠的做法是先检查Library path把旧版本相关目录全部移除只保留最新的Source目录Lib目录里那些预编译dcu不加入全局路径让编译器在需要时从Source重建dcu保证所有单元都来自当前这一份源码。加好路径后点Save然后重启IDE或至少重新打开一次工程面板让路径表生效。注意单纯在IDE运行状态下修改路径后立刻编译有时编译器缓存没有刷新会继续报找不到刚添加目录下的单元。改完路径后重启一次IDE是最省心的确认方式。3.3 编译并安装设计时包dpk的编译顺序TRichView的包分为运行时包和设计时包两类。运行时包提供类实现设计时包负责把组件注册到IDE的组件面板。安装顺序必须严格先编译运行时包再安装设计时包。反过来先装设计时包会报一堆找不到类或单元缺失的错误。在Delphi 12.3里通过File Open Project...打开运行时包对应的.dpk工程文件。包的目录结构里一般有按Delphi版本分的子目录。打开后右键工程节点选Build或走Project Build。编译输出窗口会显示每个dcu的生成情况。如果报错按顺序处理先解决第一个错误后面的错误通常是它的连锁反应。运行时包编译通过后再打开设计时包的.dpk。在Project Manager里右键设计时包节点选Install。Delphi会执行注册完成后弹窗提示注册了多少个组件组件面板上出现RichView新页。如果Install是灰的多半是设计时包不含Register过程或依赖的运行时包还没编译成功回去确认上一步。命令行方式也可以作为参考在RAD Studio命令提示符下用MSBuild编译dpk工程参数按实际目录调整msbuild D:\Components\TRichView-23.1\packages\12\RichView_Runtime.dpk /t:Build /p:ConfigRelease /p:PlatformWin64这里/t:Build指定构建目标/p:Config和/p:Platform控制配置与目标平台。大多数情况下你在IDE里点几下就能完成不需要走命令行命令行更适合后续做自动化构建或CI打包时复用。无论哪种方式只要运行时包和设计时包都从同一份Source编译安装后组件面板就能正常显示。3.4 验证安装最小工程与检查点新建一个VCL Forms Application在组件面板的RichView页签里拖一个TRichViewEdit到窗体上再拖一个TRichView。F9运行在编辑区输入多行中文选中部分文字改颜色字号确认排版实时生效。如果运行时报找不到类说明设计时包没有注册成功或工程搜索路径没指向TRichView源码目录。再做一个导出测试在设计器里给TRichViewEdit加几段格式化文本调用SaveRTF方法存成.rtf文件再用读写逻辑读回一次。这个过程能确认运行时包里的RTF序列化功能正常。如果只是把控件装上但没实测序列化某些依赖单元缺失会在这一步暴露。导出读回都成功基本能确认控件在当前机器上是可用状态后面再遇到报错往项目配置方向排查更稳妥。4. 在Lazarus里安装TRichView跨平台差异与配置要点4.1 Lazarus的包管理机制lpk与dpk的差异Lazarus使用的是Lazarus Package文件扩展名.lpk和Delphi的.dpk两套体系互不通用。dpk是Delphi原生工程文件只被Delphi识别lpk是Free Pascal工具链下的包描述文件被Lazarus的Package Manager读取。TRichView能同时支持两个IDE靠的是分发包里同时带两套包文件.dpk放在Delphi相关目录下.lpk放在Lazarus相关目录里。lpk文件内部描述了包的名称、版本、单元列表、依赖关系和编译输出目录。关键概念是Required Packages一个包声明了自己依赖哪些其他包安装时自动检查这些依赖是否存在。与Delphi一样也分运行时和设计时两部分但界面交互不同。打开.lpk后Package窗口里有Compile和Install两个按钮。Compile只是把包编译成.o和.ppu文件Install才会把包注册进IDE并触发IDE重建。一个显著差异是Lazarus安装设计时包往往要rebuild整个IDE因为组件注册代码需要被编译进IDE本身。rebuild期间IDE会显示进度条结束后自动重启看起来像IDE崩溃其实是正常流程。整个过程在一台中等配置Windows机器上大约需要两三分钟取决于机器性能。不要在rebuild期间强制关闭进程否则可能破坏IDE的二进制文件之后就得重装Lazarus。4.2 打开.lpk并编译安装在Lazarus主菜单选择Package Open Package File...定位到TRichView分发目录下的.lpk文件。打开后Package窗口会列出包内容、依赖和其他信息。先检查Required Packages每一行确认依赖的包名在当前Lazarus环境里能找到版本号不匹配的会在编译阶段直接报错。如果不知道lpk文件在哪个子目录可以用命令快速定位find . -type f -name *.lpk这条命令在包根目录下搜索所有.lpk文件输出会列出完整相对路径。TRichView通常把lpk放在lazarus子目录或插件相关目录下看到文件名后再到IDE里打开省去一层层翻目录的时间。找到lpk后点击Compile按钮观察Messages窗口。编译报错时要看完整输出尤其是第一条error。常见的错误是找不到依赖单元比如找不到LCLIntf或InterfaceBase这通常意味着当前Lazarus环境缺少某个底层包。先把依赖包装上再回来编译。编译通过后点InstallLazarus提示IDE需要重建确认后进入rebuild流程。完成后IDE自动重启组件面板出现TRichView相关页签这步才算真正完成。如果安装前已经加载过同名的旧版本包先在Package Manager里卸载旧包再装新包避免同名页签或类注册冲突。4.3 跨平台差异与配置要点在Windows上Lazarus的widgetset是Win32/Win64在Linux上常见GTK2或Qt5在macOS上是Cocoa。TRichView在Win32下表现和Delphi版本最接近到了GTK2下字体度量、DPI缩放、键盘焦点都可能略有差异。如果你在Linux下做界面建议在目标系统上实际跑一遍Demo而不是只在Windows上验证后就发布。字体方面TRichView通过TRVStyle统一配置字体名。跨平台时同一个字体名在两个系统上可能没有同名同族的对象比如Windows的宋体在Linux上没有对应。规避方法是让自定义字体在两边的系统里都存在或设置字体回退列表。TRVStyle的FontName可以在设计时填入也可以运行时根据当前平台动态设置为系统默认字体后者更省事。路径分隔符和字符编码也需要统一。Linux区分大小写路径Windows不区分代码里写死路径时要小心。字符编码上Lazarus的默认字符串是UTF-8Windows下Delphi的默认字符串是ANSI两端拿RTF交换文档时如果RTF里没有明确编码声明读取结果可能不一致。涉及跨平台数据交换的项目建议统一按UTF-8生成和读取文档并在文件头写上编码声明这样在两端都能得到一致解析。5. 安装与使用避坑指南报错现象、根因与解决方案5.1 编译时报错F1026 File not found: RichView.inc现象引入TRichView的单元后编译IDE报F1026提示找不到RichView.inc。原因TRichView源码里带条件编译指令.inc文件负责按Delphi版本和平台设置宏缺少这个文件编译器就无法解析单元内容。找不到它绝大多数情况是Source目录没有加入Library path或者加入的路径拼写有误。解决在Delphi的Tools Options Language Delphi Library里用Browse按钮把TRichView的Source目录正确加入32位和64位平台两行都要加。保存后重启IDE再编译一次如果仍然报错用命令行输出检查实际搜索路径确认Source目录物理上有RichView.inc这个文件。这类问题大概率是自己改路径时手滑先检查路径再动代码解决起来会快得多。5.2 组件面板上找不到TRichView现象按第3章的步骤完成了dpk的打开和Build但新建工程后组件面板上找不到RichView页签或者页签里没有控件。原因绝大多数情况是安装的是运行时包而不是设计时包。运行时包只提供类实现不负责把控件注册到IDE面板只有含Register过程的设计时包才会在安装时向IDE注册组件。包管理器里的Install按钮状态能帮你判断按钮是灰的一般说明当前包不是设计时包。解决在设计时包对应的.dpk工程上右键选择Install。如果Install不可用先在同一环境下把运行时包Build出来再回到设计时包右键后选Build Then Install。TRichView这种多包组件存在依赖关系设计时包依赖运行时包顺序必须正确。安装后仍然看不到页签还可能因为IDE里存在多个同名页签新注册组件被排到后面的页签去了拖动页签标签翻一遍再确认。5.3 Lazarus下中文或UTF-8内容乱码现象在Lazarus里用TRichView打开含中文的RTF文件显示成乱码或问号。原因问题往往出在RTF文件的编码声明与实际内容编码不一致。老RTF文件常用ANSI编码中文环境下通常是GBK但声明里写的代码页不匹配或者内容已经是UTF-8却没有BOMTRVRTFReader按默认代码页解析自然乱码。Lazarus的默认字符串又是UTF-8双重作用下中文很容易翻车。解决用文本编辑器打开RTF文件查看前几行的编码声明。如果是UTF-8编码确保文件有UTF-8 BOM或者显式配置Reader属性来处理Unicode内容。如果是GBK编码需要确认Reader能识别对应代码页或先转码再导入。在Lazarus侧代码里的字符串类型统一用Utf8String不要隐式转成AnsiString在Delphi侧则反过来Windows默认是ANSI跨平台交换时多加一道显式编码转换能规避大部分乱码问题。5.4 切换到64位目标后报dcu找不到现象在Delphi 12.3的32位平台编译一切正常切换64位平台后报dcu文件缺失或无法解析。原因TRichView按平台分目录输出dcu通常32位和64位的输出路径不同。如果Library path只配置了32位的输出目录64位编译器去旧目录找dcu自然找不到。如果之前的预编译dcu只有32位版本64位编译同样会失败。解决在Project Options里把64位平台的Output directory设置成TRichView对应的64位目录目录名通常带有x64或Win64字样。更稳妥的做法是在64位平台下手动重新Build一次TRichView的运行时包让编译器按当前平台生成dcu并写到正确目录。切换平台时先把IDE缓存清理一遍避免新旧dcu混在同一输出目录里。5.5 运行时提示类未注册或接口不一致现象工程编译通过运行时创建TRichViewEdit或调用某个Writer时报错提示找不到注册类、接口不一致或访问违例。原因设计时包和运行时包不是由同一份源码编译出来的。比如运行时包链接的是Lib目录里的预编译老dcu设计时包却是从新源码编译的两边的方法签名、字段偏移和RTTI信息不一致实例化时就崩溃。解决强制让两个包都从同一份源码编译。最可靠的操作是把Library path里的预编译Lib目录全部移除只保留Source目录在IDE中先Build运行时包再Build并Install设计时包连续完成结束后重启IDE。很多看起来玄学的报错其实就是路径里混进了多版本dcu清理干净后自然不再出现。6. 跑通第一个富文本编辑器最小Demo与实用参数设置6.1 最小可编辑Demo新建VCL或LCL工程放一个TRichViewEdit设为rvEdit。窗体的OnShow里写procedure TForm1.FormShow(Sender: TObject); begin rvEdit.Clear; rvEdit.AddText(Hello, TRichView in Delphi 12.3.); rvEdit.AddText( 这是中文测试文本。, 0, clRed); rvEdit.Format; end;AddText的第二个参数是文字颜色第三个参数是背景色0表示沿用默认值。最后的Format通常不能省AddText只是改了文档树界面上的排版和滚动范围需要Format触发重排。6.2 三个实用参数设置Style属性值得优先调把TRVStyle的字体、字号、段落间距设成项目统一值赋给编辑控件的Style属性所有新建文档会从同一套默认样式开始不用逐个段落设置。Options里的编辑行为参数我一般会打开roAllowDragDrop关闭roWheelZoom。roWheelZoom在编辑大文档时容易被触摸板误触发造成内容意外缩放。RTF读取容错参数则更偏防御TRVRTFReader对未知属性的容忍度可以调高读到不认识的属性就跳过而不是让整个导入中止。具体属性名以23.1版文档为准思路是一致的——外部用户上传的RTF什么怪格式都有容错调高能少崩几次。6.3 验证安装每次在一台新机器上装完我习惯花三分钟做三个检查能放控件并运行能输入中文并改颜色字体能导出RTF再读回内容和导出前一致。三个都通过说明环境基本没问题之后再出问题多半是业务代码或项目配置而不是控件装错了。装控件这件事最怕在路径和包顺序上图省事把之后所有报错都变成黑匣子。我现在每装一个包先把Library path截图存一份再把编译顺序写进项目文档。时间久了你会发现这些前置步骤越仔细后面的项目构建越省心。希望这篇能帮你在自己的环境里顺利装好TRichView并跑起来。本文还有配套的精品资源点击获取