Delphi VCL电子表格控件源码解析与二次开发实践

简介：面向需要深度定制电子表格控件的 Delphi 与 C++ Builder 开发者，这份 DevExpress.ExpressSpreadSheet v1.38 源代码提供了研究表格引擎、公式解析、数据绑定、样式格式与界面渲染实现方式的完整素材，也适合二次开发、性能调优和兼容性排查时对照参考。压缩包共 382 个文件、约 2.81MB，其中 73 个 pas 单元与 38 个 cpp 源文件承载主要逻辑，45 个 dpk 包定义、26 个 dfm 窗体、83 个 res 资源及若干项目组文件共同构成可编译的工程结构，并包含 ExpressGDI+ 图形绘制、核心公共库与主题管理等模块。已有 447 人学习，说明其在同类组件源码资料中具备一定参考价值。读者可借此理解组件分层架构与 API 组织方式，掌握复杂计算、数据导入导出和用户界面交互的实现思路，并依据项目需求裁剪功能、定位问题。

1. 一份带源码的 VCL 电子表格控件，能省掉多少排查时间

接手一个跑了七八年的老报表模块，最难受的不是需求变更，而是原来那套表格控件只剩编译好的 dcu 和 bpl，公式少算一分钱，你连从哪一行查起都不知道。这次我把 DevExpress SpreadSheet 1.38 的源代码包整个翻了一遍，就是因为这个：一套跑在 Delphi / C++Builder 上的 VCL 电子表格控件，单元格模型、公式引擎、样式系统、xlsx 导入导出全在里面，出问题能一路跟到实现层，而不是对着黑匣子猜。

它适合两类人：一类是维护老桌面项目、必须在不换框架的前提下把表格能力焊进程序的开发者；另一类是想搞清楚「一个电子表格控件内部到底怎么组织数据和重算」的人。1.38 这个版本不算新，但正因为老，代码里没有太多为了兼容新编译器加的糖，读起来反而直。

2. 源码包结构与编译前提：从目录到第一个可运行窗体

拿到压缩包后，先不要急着打开工程文件。这类 VCL 控件包的结构都遵循同一套逻辑：运行期代码、设计期注册、示例工程、资源文件四块分开。分不清这四块，后面编译报错时会一直卡在「明明路径加了却找不到单元」这种地方。

2.1 目录分工：运行期包、设计期包和示例各管什么

我手上这份 1.38 的包，按职责大致可以拆成下面几块。不同小版本的目录名会有出入，但分层是一致的：

关键点是运行期包和设计期包是两个独立工程。设计期包在 requires 里引用运行期包，只负责注册；运行期包才是真正被业务程序链接的东西。很多新手把设计期包当成主包去编译，结果 Install 成功、拖控件也正常，但一编译自己的程序就报找不到单元——因为业务程序链接的是运行期包，而它压根没编译出来。

提示：先把运行期包单独 Build 一遍，确认能在$(BDS)\lib或你指定的输出目录里看到 bpl 和一堆 dcu，再去动设计期包。

2.2 编译前置：版本、搜索路径与字符集

1.38 这个年代的包，配套的编译器区间大致是老版本到 XE 早期那一段。用太新的编译器打开，第一波报错通常来自字符集和泛型容器，不是代码逻辑问题。

搜索路径是第二个高频问题。这类控件的单元之间是互相引用的，核心单元 uses 公式单元，公式单元 uses 基础类型单元，你把 Source 根目录加进搜索路径是不够的，得把 Source 下所有子目录都加进去，或者干脆把整棵树加进去。我一般会新建一个独立的编译配置，把这些路径写死在这个配置里，避免污染全局环境。

// 运行期包工程文件（.dpk）的骨架，重点看 requires 和 contains package ExpressSpreadSheetRTL; requires rtl, vcl, vclx; contains dxSpreadSheetCore in 'Source\Core\dxSpreadSheetCore.pas', dxSpreadSheetClasses in 'Source\Core\dxSpreadSheetClasses.pas', dxSpreadSheetFormulas in 'Source\Formula\dxSpreadSheetFormulas.pas', dxSpreadSheetFunctions in 'Source\Formula\dxSpreadSheetFunctions.pas', dxSpreadSheetXlsx in 'Source\Formats\dxSpreadSheetXlsx.pas'; end.

这段的意义在于：requires里只能出现 IDE 自带的包名，不能写第三方包；contains里列出的单元顺序不代表编译顺序，编译器会自己解依赖，但文件路径必须是相对 dpk 的正确相对路径。如果你把 dpk 从原目录挪出来单独放，那些相对路径全断，报的错是「找不到文件」而不是「找不到单元」，这两种错误要分清。

字符集方面的经验：老版本默认走 AnsiString，D2009 之后默认 UnicodeString。这套源码里如果有大量string和AnsiString混用，在中文字符串上会出现截断或者问号。常见做法是在编译配置里把String的默认类型固定下来，然后全量重编一次，不要一半用旧 dcu 一半用新源码。

2.3 装进 IDE：三步拖出第一个表格窗体

包编译通过之后，打开设计期包工程，Build，然后右键 Install。工具面板上会出现一个组件页，里面就是那个表格控件。验证流程建议按下面三步走，每步都能独立确认一件事：

第一步，新建一个空白 VCL 窗体程序，把控件拖上去，Align设成alClient。能拖上去说明设计期注册成功。

第二步，编译运行。能起来说明运行期包链接正常，这一步过不了基本就是 bpl 路径问题。

第三步，在窗体上放一个按钮，代码里往单元格写点东西。

procedure TFormMain.FormCreate(Sender: TObject); var ASheet: TdxSpreadSheetTableView; begin // Sheets[0] 默认就是一个表格视图，直接转成 TableView 用 ASheet := dxSpreadSheet1.Sheets[0] as TdxSpreadSheetTableView; // 批量写之前先挂起重绘，写完再放开，否则每写一格都刷一次界面 ASheet.BeginUpdate; try ASheet.Cells.CreateCell(0, 0, True).AsString := '产品名称'; // 参数顺序：列, 行 ASheet.Cells.CreateCell(0, 1, True).AsString := '一月'; ASheet.Cells.CreateCell(1, 0, True).AsString := 'A 型'; ASheet.Cells.CreateCell(1, 1, True).AsFloat := 128000.50; finally ASheet.EndUpdate; end; end;

CreateCell(ACol, ARow, True)的三个参数分别是列索引、行索引、以及单元格不存在时是否自动创建。第三个参数传 False 时，如果那个位置没有单元格对象，返回的是 nil，直接链式赋值会访问违例。这是这套控件最容易翻车的一处，后面第 5 章还会展开。

3. 对象模型拆解：一套 VCL 表格控件的分层设计

读源码最怕一上来就扎进绘制代码。这套控件的正确读法是先看对象模型——把「谁是数据、谁是表现、谁负责交互」这三件事分清楚，后面的代码基本就是填空题。

3.1 控件层与数据层：控件、Sheet、View 的三层关系

顶层是那个你拖到窗体上的控件类，它继承自一个自定义控件基类，负责窗口句柄、焦点、滚动条、输入法这些 VCL 层面的东西。它自己不存单元格数据，只持有一个 Sheet 集合。

中间层是 Sheet。工作簿概念的载体，Sheets[0]、Sheets[1]就是这样来的。Sheet 又分不同视图类型，最常见的就是表格视图（TableView），你能看到行列表格的那种。源码里这个分工很明确：TableView 管行列结构、单元格容器、合并区域、选择区；另一个兄弟类管滚动条与视图信息（ViewInfo），负责「当前可见区域是哪些行列、每列多宽」。

底层才是单元格对象和它的样式对象。这个分层带来一个很实际的好处：同一个 Sheet 上可以挂多个视图，一个负责显示、一个负责打印布局，数据只有一份。二次开发时如果要做「同数据两种展现」，不用复制数据，加视图就行。

我建议读源码的顺序是：先看控件类的 published 段，把所有对外暴露的属性按「外观 / 行为 / 数据」三堆分类；再看 Sheet 类的 published 段；最后才进单元格和绘制。这样你对 API 的边界会先建立起来。

3.2 单元格存储：稀疏结构与内存的真实开销

单元格不是二维数组。如果 1000 行 × 100 列都预分配对象，光对象头就够呛，而且绝大多数格子是空的。这套源码用的是稀疏存储：行列结构（行高、列宽、隐藏标记）单独维护，单元格对象按需创建，只有被写过值或样式的格子才在容器里占一个位置。

Cells[ACol, ARow]这个索引器在读的时候，如果那个位置没有对象，通常返回一个空的占位单元格，让你读到的值是空字符串、0 或者 Null，而不是抛异常。但写的时候不一样，写之前必须保证对象存在，这就是CreateCell存在的理由。

参数顺序是列在前、行在后，这跟很多人的直觉相反。Delphi 的StringGrid也是这个顺序，所以从 StringGrid 迁移过来的人反而不会错，从 Excel 那种 A1 记法思维过来的人会频繁写反。

内存估算上，单个单元格对象的开销大约是几十字节级别，加上样式对象如果每格独立创建会更贵。所以真实项目里 10 万格以上的表，我一般会做两件事：一是相同样式的单元格共享同一个样式对象（源码里样式对象本身就支持引用计数式的复用），二是超过一定规模就改成只创建有数据的格子，其余靠默认样式渲染。

// 大数据量写入的正确姿势：先算好范围，按需创建，全程挂起重绘 procedure TFormMain.FillLargeTable(ASheet: TdxSpreadSheetTableView; ARows, ACols: Integer); var R, C: Integer; ACell: TdxSpreadSheetCell; begin ASheet.BeginUpdate; // 挂起重绘与布局计算 try for R := 0 to ARows - 1 do for C := 0 to ACols - 1 do begin ACell := ASheet.Cells.CreateCell(C, R, True); if ACell = nil then Continue; // 极端情况下创建失败，跳过而不是崩 ACell.AsFloat := R * ACols + C; // 这里换成你的业务数据 end; finally ASheet.EndUpdate; // 一次性重算布局并刷新 end; end;

BeginUpdate/EndUpdate是这套代码里性价比最高的一个优化点。它内部是一个计数器，可以嵌套，只有计数归零时才真正触发重绘和布局重算。循环里少这一对调用，5000 行数据能卡到十几秒；加上之后通常在一秒以内。

3.3 公式引擎：解析、依赖表与重算顺序

公式这块是整套源码里最值得读的部分。它的处理链路大致是四段：

第一段是解析。单元格里存的公式字符串（以等号开头那段）被词法分析切成记号，再按运算符优先级组装成语法树。源码里这部分被拆成独立的单元，跟界面完全解耦，你甚至可以在控制台程序里单独引用来算表达式。

第二段是函数实现。SUM、IF、VLOOKUP 这类内置函数，每个函数对应一个实现类，统一继承同一个基类，基类定义了参数个数校验、参数求值、返回值的接口。注册表是一张「函数名 → 实现类」的映射，解析到函数名时去查表。这也是最容易扩展的地方——加一个自定义函数就是加一个类加一行注册。

第三段是依赖关系。每个公式单元格记录它引用了哪些单元格区域，反向再维护一张「谁依赖我」的表。改一个单元格的值时，靠这张反向表找出所有需要重算的格子，打上脏标记。

第四段是重算。脏标记收集完之后按依赖顺序求值，遇到循环引用要有检测机制，否则就是无限递归。常见做法是设一个迭代上限，超过就跳出并把单元格标记成错误值。

理解这条链路的价值在于：当用户反馈「改了 A1，B1 的公式没跟着变」，你能立刻判断是脏标记没打上、还是重算没触发、还是依赖表没建对。三种原因的修法完全不同。

4. 关键实现逐段读：赋值、公式、导入导出三条链路

对象模型清楚之后，就可以挑三条最常用的链路来读实现了。这三条链路覆盖了日常开发 90% 的调用。

4.1 写一个单元格到底走了多少层

表面上看是一行赋值，实际经过的层次不少：控件层收到调用，转发给 Sheet；Sheet 定位到单元格容器；容器判断对象是否存在，不存在就创建；创建时套用默认样式；赋值时判断值类型，数字和字符串走不同的存储分支；最后标记该区域为脏，等待重绘。

procedure TFormMain.WriteCellWithStyle(ASheet: TdxSpreadSheetTableView; ACol, ARow: Integer; const AText: string); var ACell: TdxSpreadSheetCell; begin ACell := ASheet.Cells.CreateCell(ACol, ARow, True); if ACell = nil then Exit; ACell.AsString := AText; // 样式对象改之前也要挂起，否则每改一个属性就触发一次重排 ACell.Style.BeginUpdate; try ACell.Style.Font.Style := [fsBold]; ACell.Style.Font.Size := 10; // TColor 是 $00BBGGRR，不是 RGB，写反了颜色就成蓝的 ACell.Style.Brush.Color := $00E8F4FF; ACell.Style.HorzAlign := taLeftJustify; ACell.Style.VertAlign := vaCenter; finally ACell.Style.EndUpdate; end; // 数字格式沿用样式对象上的格式串，千分位、百分比都靠它 end;

这段里有两个参数细节值得说。Brush.Color用的是 Delphi 的TColor，低字节是红、中间是绿、高字节是蓝，跟 Web 上的 RGB 顺序相反，从设计稿抄色值过来必须做一次转换。HorzAlign/VertAlign是这套控件的对齐属性，不是 VCL 标准控件的Alignment，从别的表格控件迁代码时容易写错。

4.2 公式从字符串到结果：解析器与函数注册

给单元格赋公式，和赋值是两条路。赋公式走的是解析入口，解析成功之后语法树挂在单元格上，同时登记依赖；解析失败则整格变成一个错误值。

var ASheet: TdxSpreadSheetTableView; ACell: TdxSpreadSheetCell; begin ASheet := dxSpreadSheet1.Sheets[0] as TdxSpreadSheetTableView; // 求和格：公式本身存字符串，结果由引擎算 ACell := ASheet.Cells.CreateCell(1, 10, True); ACell.Formula := '=SUM(B2:B11)'; // 引用另一格的公式 ACell := ASheet.Cells.CreateCell(2, 10, True); ACell.Formula := '=IF(B12>0, B12*0.13, 0)'; // 批量改完之后统一重算一次，比每改一格算一次快得多 // 重算入口挂在公式控制器上，具体方法名看源码里控制器单元的 public 段 end;

读这段源码时注意几个边界。一是公式字符串一定要带等号，不带等号会被当普通文本处理，界面上看不出来但结果永远是字符串。二是区域引用B2:B11的解析跟单个引用走不同分支，区域引用内部展开成行列范围，跨表引用的写法还要额外带表名。三是重算不是实时的——改了被引用的单元格，引用方不会立刻变，要等重算触发。这是性能考量，但也是新手最容易误判成 bug 的地方。

自定义函数的扩展点在函数注册表上。源码里每个内置函数是一个类，实现求值方法，构造时从参数列表里取实际值。加自己的函数就是照抄一个最简单的内置函数，改个名字，改个求值逻辑，再在注册表里登记一行。业务上常见的「按自定义汇率换算」「按工号查部门名」，都可以这样接进去，让用户在公式里直接写。

4.3 xlsx 导入导出：格式适配层在哪

导入导出这块，源码里是一层独立的适配代码，职责是把内部对象模型和文件格式之间做双向映射。xlsx 本质是一个 zip 包，里面几个固定的 xml：工作表、共享字符串表、样式表、工作簿关系。

procedure TFormMain.LoadAndSave(const AInFile, AOutFile: string); begin // 加载：内部会解压、解析 xml、重建单元格与样式 dxSpreadSheet1.LoadFromFile(AInFile); // 加载完最好确认一下工作表数量，空文件或者结构异常时这里能第一时间发现 if dxSpreadSheet1.Sheets.Count = 0 then Exit; // 改数据……（略） // 保存：把当前模型重新序列化成 xlsx dxSpreadSheet1.SaveToFile(AOutFile); end;

适配层里有两个实现细节值得注意。一个是共享字符串表，xlsx 里重复出现的字符串只存一份，单元格里存索引，导入时要建索引到字符串的映射，导出时要做去重，这一步做不好，大表导出体积会翻几倍。另一个是公式的存储方式，xlsx 里公式节点存表达式文本，同时可以存一个缓存值。如果导出时不写缓存值，某些不重算的阅读器打开会看到空白；如果写了缓存值又跟公式对不上，就会看到「数字是旧的，点进去公式是新的」这种诡异现象。

注意：导出后拿 Excel 打开对一遍，重点看三类：公式结果、日期格式、合并单元格。这三类是最容易在序列化时丢信息的。

4.4 绘制：为什么滚大表不卡

绘制这部分很多人跳过，但它解释了一个实际现象：为什么同样十万行数据，有的表格控件滚动丝滑，有的卡成 PPT。核心是虚拟化——只绘制当前可见区域的行列，不可见的完全不参与布局计算。行高列宽算一次缓存起来，滚动时只做偏移量换算，不做重新测量。

读这块源码能学到一个通用套路：把「数据规模」和「绘制规模」解耦。数据可以十万行，绘制永远只有屏幕上那几十行。二次开发时如果要加自定义绘制（比如给某类单元格画角标），挂到单元格绘制事件上就行，不要试图遍历全部数据去找要画的东西。

5. 踩坑排查：编译报错、行列颠倒、公式不重算

这一章是我自己踩过、以及帮别人看代码时反复见到的几类问题，按「现象 → 原因 → 解决」记下来。

5.1 编译报「单元版本不一致」

现象：包本身能编译，但业务工程一引用就报某个单元是用不同版本编译的，或者报找不到某个 dcu。

原因：搜索路径里同时存在旧版 dcu 和新编译出来的 dcu，编译器按路径顺序先找到了旧的。也可能是当初只重编了部分单元，其余的 dcu 还是老编译器产物。

解决：把源码目录、输出目录、系统 lib 目录下所有相关 dcu 清一遍，然后从运行期包开始全量 Build，再 Build 业务工程。清 dcu 这个动作看着粗暴，但它能排除掉 90% 的「玄学编译错误」。血泪经验是：只要改过编译配置里的字符集或者条件编译开关，就必须全量重编，不能增量。

5.2 数据整体错位一格

现象：写进去的数据在界面上整体偏了一行或者一列，或者第一行永远空着。

原因：Cells[ACol, ARow]是列在前、行在后。从 Excel 的 A1 思维或者从一维数组思维过来的人，很容易写成Cells[Row, Col]。

解决：在自己的代码里做一层封装，别在业务代码里直接调Cells。封装函数的参数按业务语义命名（比如SetCell(Row, Col, Value)），内部统一转成控件的顺序。这样即使以后换控件，改一处就行。我一般会把这个封装做成一个 helper 类，顺手把CreateCell的判空也包进去。

5.3 公式算出来全是 0 或者不刷新

现象：公式文本是对的，但单元格显示 0；或者改了被引用的格子，公式格纹丝不动。

原因：三种可能。一是赋公式时字符串没带等号，被当成文本；二是整批写入时BeginUpdate之后忘了配对的EndUpdate，重绘和重算都被挂起；三是值改了但没触发重算，脏标记没打上。

解决：先确认公式字符串带等号；再检查BeginUpdate/EndUpdate是否成对且没有在异常路径里漏掉finally；最后手动触发一次全量重算，看结果对不对。如果手动重算对、自动重算不对，那就是依赖登记的问题，回去看引用解析那段的实现。

5.4 大数据量下界面卡死

现象：一次性写入几万格，窗口假死几十秒，任务管理器显示 CPU 单核跑满。

原因：没有批量挂起重绘，每写一格都触发一次布局计算和界面刷新；另外每个单元格都独立创建样式对象，内存和 GC 压力都大。

解决：写入全程包在BeginUpdate/EndUpdate里；样式尽量复用，相同格式的格子共享同一个样式对象；实在太大就分批写，每批之间Application.ProcessMessages让界面喘口气（这一招有副作用，只在导入场景用，正常编辑流程别用）。

5.5 中文导出后变乱码

现象：程序里显示正常，导出成 csv 或者 xlsx 再用别的软件打开，中文变成问号或者方块。

原因：字符集不统一。老版本源码默认 AnsiString，导出时按本地代码页写；新编译器默认 Unicode，中间某一步做了隐式转换丢了信息。csv 还额外有 BOM 的问题。

解决：全链路统一成宽字符串或者 UTF-8，导出 csv 时显式写 BOM，xlsx 走 xml 序列化那条路本来就没问题——如果 xlsx 也乱码，那问题在字符串表那一层，去看共享字符串的写入口。

6. 二次开发：把它改成业务里的报表引擎

源码能编、能跑之后，真正的活儿才开始。直接拿控件 API 铺业务代码，写三个报表就乱成一锅粥。我的做法是在控件外面套一层薄适配层，把「业务数据」翻译成「表格模型」，业务代码只认适配层。

改造点我按优先级列一下：

数据适配层是这样写的：定义一个描述表格结构的记录，包含列定义（标题、宽度、对齐、数字格式）和数据源；再写一个Render方法，遍历数据源往 Sheet 里填。这样做的好处是，同一个报表既能渲染到控件，也能走导出流程，代码只有一份。

type TColumnDef = record Title: string; Width: Integer; IsMoney: Boolean; end; procedure TRenderer.Render(ASheet: TdxSpreadSheetTableView; const ACols: array of TColumnDef; const ARows: TArray<TArray<Variant>>); var C, R: Integer; ACell: TdxSpreadSheetCell; begin ASheet.BeginUpdate; try // 表头 for C := 0 to High(ACols) do begin ACell := ASheet.Cells.CreateCell(C, 0, True); ACell.AsString := ACols[C].Title; ACell.Style.Font.Style := [fsBold]; end; // 数据区 for R := 0 to High(ARows) do for C := 0 to High(ACols) do begin ACell := ASheet.Cells.CreateCell(C, R + 1, True); if ACell = nil then Continue; if ACols[C].IsMoney then ACell.AsFloat := VarToFloatDef(ARows[R][C], 0) else ACell.AsString := VarToStr(ARows[R][C]); end; finally ASheet.EndUpdate; end; end;

这段的关键不是代码本身，而是边界：表头固定在行 0，数据从行 1 开始，列索引直接用数组下标。业务侧只需要提供列定义和二维数据，不关心单元格、样式、行列顺序。以后要加「隔行底色」「负数标红」，改Render一处就行。

验证方法我一般用对拍：同一批数据，一边用控件渲染后导出 xlsx，一边用 Excel 手工算一遍关键指标，把两边结果拉到一起比对。金额类的字段精确到分，公式类的字段抽查几条带条件分支的。这个过程很枯燥，但比上线后被财务追着问强。

还有一个技巧值得单独说：别急着改源码。这套控件的扩展点已经够多了，函数注册、绘制事件、格式适配都能挂自己的代码，不到万不得已不要去改核心单元。改了之后每次升级版本都要合并一遍，成本很高。确实要改，就在自己的单元里继承它的类做子类化，把改动收敛在一个文件里。

从那以后我每次接手这种带源码的控件包，都先把运行期包单独编一遍、跑一遍示例、把 published 段扫一遍，确认自己理解了它的边界再动业务代码，再没出现过「编译通过但运行时崩」的返工。希望帮到你。

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