简介在软件开发中基于组件的复用是提升工程交付效率的关键路径。Delphi 生态的 VCL 框架通过封装高频业务逻辑帮助开发者快速搭建桌面应用界面。然而从 Delphi 7 升级到 Delphi 10 Seattle 时控件源码的跨版本兼容与编译部署往往成为老项目现代化改造的主要痛点。TMS Component Pack 8.0.9.0 提供了一套覆盖多编译器的Full Source组件包借助条件编译与分版本包管理机制让一套源码在 D7 和 DX10 下产出对应 BPL兼顾界面一致性与维护效率。无论是替换旧版控件、迁移遗留系统还是以静态链接方式发布生产环境这套方案都为 Delphi 工程提供了可行的升级路径。1. TMS Component Pack 8.0.9.0 是什么为什么老项目都在抢这套 Full Source一个做 Delphi 开发的老工程师手里同时维护着 D7 时代的遗留系统和基于 DX10 的新项目最头疼的事就是两套代码库的 UI 组件对不上。TMS Component Pack 8.0.9.0 Full Source 就是为解决这个问题来的一套源码从 Delphi 7 一路覆盖到 Delphi 10 Seattle表格、图表、HTML 控件、右键菜单、组织架构图这些高频业务组件全在里面并且是带完整源码的版本。跟试用版或闭源评估版不同Full Source 意味着你可以在 D7 和 DX10 下各自编译出对应版本的 BPL甚至改它的源码来适配自己项目的奇奇怪怪需求。这套组件尤其适合还在维护老系统、又不想被第三方控件版权锁死的团队——买一次装全家老编译器和新编译器都能用。2. Full Source 包的结构与版本适配逻辑从 D7 到 DX10 的编译路线2.1 一套源码凭什么通吃 D7 和 DX10条件编译与包名分流第一次拿到 TMS Component Pack 8.0.9.0 的源码目录大多数人会愣一下因为打包结构不像普通 VCL 组件那样只有一个统一的 .dpk而是按照编译器版本拆成了十几个子目录。这套源码能做到 D7 到 DX10 通吃核心依赖两个机制条件编译指令和按版本的包文件分流。条件编译是 VCL 组件最常见的兼容手法。在 TMS 源码里你经常能看到这样的判断{$IFDEF VER150} // Delphi 7 // D7 下的特殊处理 {$ENDIF} {$IF CompilerVersion 27} // XE6 以上 // 新版编译器特性 {$IFEND}VER150是 Delphi 7 的内部版本号而CompilerVersion 27这类写法是为了在 XE 系列以后的编译器上启用新的语言特性。TMS 8.0.9.0 的做法是核心控件代码尽量用跨版本兼容的 VCL API只有在某些 API 在新版里被标记为 deprecated 或者彻底移除时才用条件编译切换到替代实现。另一个机制是包文件分流。每个子目录里放着对应版本的 .dpkDelphi Package 工程比如 D7 下编译用 .dpk而从 XE 开始则多用 .dpkgDelphi Package 工程组和 .dproj。同名的 .pas 文件在不同版本目录里可能略有差异这取决于 TMS 在这个版本里是否针对编译器特性做了微调。2.2 动手前的识别工作看目录、找 dpk/dproj分清设计时包和运行时包在跑任何编译命令之前先把包的类型和依赖关系理清楚。TMS Component Pack 里绝大多数控件都遵循同一套命名规则TMS...R是运行时包Runtime PackageTMS...D是设计时包Design-Time Package。运行时包装的是控件本体负责你程序在客户机器上的行为设计时包只在 IDE 里起作用负责把控件实例注册到 Delphi 组件面板上。以我习惯的落地流程第一步不是双击任何一个 .dpk而是先打开源码根目录的 README 或 Install.txt8.0.9.0 版本在根目录下一定有这类说明文件确认当前这版组件支持的 Delphi 版本范围和推荐的安装入口。这些说明文件是 TMS 团队唯一会在新版本里认真更新的东西值得花五分钟读完。第二步是拉开目录结构找到对应版本目录下的包文件。比如Packages\D7下放的是 D7 专用的*.dpkPackages\DX10下放的是 DX10 的*.dproj。8.0.9.0 这个版本对 D7 和 DX10 的支持是两个独立安装路径不存在一个包文件同时编译到两个版本的情况这跟 ActiveX 控件那种“一次注册到处用”有本质区别——你在 D7 下编译过的 BPL拿来给 DX10 用是绝对会翻车的。2.3 制定你的编译顺序依赖是第一位排序不是玄学TMS Component Pack 内部有严格的依赖关系不是说你随便打开一个包就能编过。常见的依赖链条是TMSBase/TMSCommon这类基础包在最底层完成公共数据结构、绘制函数、日志等通用功能往上一层是TMSGrid这类中等规模包依赖基础包最上层才是TMSAdvancedCharts、TMSDiagram这种大型复合控件依赖前面所有包。这里有一个血泪经验不要跳出厂的 Install 脚本自己想着“我只用 Grid 功能就编 Grid 一个包试试”。因为一旦某个包引用了底层包里的类型而你跳过了依赖编译Delphi 的包编译器会报E2201找不到 xxx.dcu到时候你还得回头把依赖链摸一遍。我一般会这样做先把所有基础的运行时包用命令行批量编译再进 IDE 安装设计时包。命令行编译省掉了 IDE 里每个包弹窗确认的时间而且失败时错误信息更集中。# 在 DX10 版本目录下用 msbuild 编译指定的设计时包工程 cd C:\Components\TMS8.0.9.0\Packages\DX10 msbuild /t:Build /p:ConfigRelease TMSGridD.dproj这句话的意图是让 MSBuild 按 Release 配置编译TMSGridD.dprojGrid 的设计时包。如果你看不到.dproj文件说明这版对应的目录是 D7 等老编译器那么要用命令行dcc32来编译.dpkdcc32 -B -M -Q -JPHNE TMSGridD.dpk-B表示全量重编译-M是允许构建所有依赖单元-JPHNE告诉 dcc32 同时生成dcu/bpl/dcp等产物。注意 D7 时代的 dcc32 不认识.dproj同样 DX10 的 msbuild 也基本不认.dpk选错编译入口等于没跑。提示在纯命令行编译时-Q和安静模式容易把关键错误日志刷掉建议去掉-Q让问题直接暴露在输出里。编译成功后你会在同目录下看到生成的.bpl和.dcu文件这就是后面安装和部署要用的东西。3. 从 D7 到 DX10 的实际安装步骤环境准备、路径配置与包编译3.1 环境准备别让旧版 IDE 死在新系统上Delphi 7 的 IDE 在 Windows 10 和 Windows 11 上有一个知名问题代码编辑器区域出现奇怪的字体拉伸或者光标闪烁跳动无法正常输入。这跟 TMS 本身无关但如果你要维护 D7 项目这套问题会直接影响你安装组件的操作。常见做法是将 D7 的 IDE 主程序 bds.exeDelphi 7 是Delphi32.exe设置成 Windows XP SP3 兼容模式并把“替代高 DPI 缩放行为”设为“系统”reg add HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers /v C:\Program Files (x86)\Borland\Delphi7\Bin\Delphi32.exe /t REG_SZ /d WINXPSP3 /f上面这条命令是在注册表里写入兼容性标记把 D7 IDE 的兼容模式改成 Windows XP SP3。高 DPI 的设置可以右键 Delphi32.exe在兼容性页面直接勾选注册表方式适合你批量部署到公司多个开发机时使用。DX10 这边的环境准备相对简单确保系统装有对应版本的 Windows SDK并且 Delphi 的 IDE 里Tools Options Library路径不包含中文或带空格的目录否则编译 TMS 源码时会出现F1027文件找不到的错误实际上是因为路径解析异常。3.2 最小编译命令用命令行把 DesignTime 包打出来环境就绪后先别急着开 IDE。对于 TMS Component Pack 8.0.9.0 Full Source 这类包我会先手动编译一个“标杆包”——比如 5 分钟能编完的TMSBaseR运行时包快速验证整个工具链是否正常。在 DX10 目录下命令行就是cd C:\Components\TMS8.0.9.0\Packages\DX10 msbuild /t:Build /p:ConfigRelease /p:PlatformWin32 TMSBaseR.dproj/p:PlatformWin32这个参数值得单独说DX10 支持 Win32 和 Win64 两种平台TMS 源码里极少有专门为 64 位写死逻辑的地方但建议至少先把 Win32 版本跑通。等到项目需要 64 位发布时再把同一个 .dproj 用 /p:PlatformWin64 重新编译一次。如果你用的是 D7没有 msbuild 更没有 .dproj那么最小编译命令是这样cd C:\Components\TMS8.0.9.0\Packages\D7 dcc32 -B -M -JPHNE -D TMSBaseR.dpk这里的-D是指定编译输出目录也可以省略默认输出到当前目录。D7 下的一个细节坑dcc32默认只编译当前包但 TMS 的依赖比较深-M这个参数必须带上它表示“构建所有需要的单元”否则会很快报出找不到基础包编译产物的问题。3.3 在 IDE 里注册包的完整流程Library Path 与 Component 注册命令行能跑通后再进 IDE 做设计时包注册才算有底气。这一步本质上要解决两件事一是让 IDE 知道去哪找编译好的 .dcu 和 .dcp 文件二是把设计时包里的控件装上组件面板。先配置 Library 路径。在 DX10 的 IDE 菜单里打开Tools Options Delphi Options Library Library Path添加以下目录按你的安装路径调整C:\Components\TMS8.0.9.0\Packages\DX10\Source C:\Components\TMS8.0.9.0\Packages\DX10\Lib\Win32\Release第一段是 TMS 源码目录IDE 需要它来查找 .pas 文件第二段是上一步编译输出的 .dcu 目录。在 D7 里对应的是Tools Environment Options Library Library Path填法一样。这里千万别只加一个源文件目录却漏了输出目录否则编译引用 TMS 包的项目时会报“找不到 .dcu”的错误但 IDE 看起来又是装着组件的这种半装半卸的状态最容易让人翻车。Library 路径配好后再装设计时包。用Component Install Packages Add找到对应的设计时 .bpl比如dclTMSGridD.bpl或TMSGridD.bpl点 OK 后正常情况下 IDE 的组件面板会多出一个 TMS 页签里面有 AdvStringGrid、AdvColumnGrid 等控件可以拖拽。这一步如果没出现 TMS 页签最常见的原因是设计时包的编译配置和 IDE 当前配置不一致比如你编译的是 Release但 IDE 当前运行的是 Debug 配置那么设计时包加载会静默失败。解决办法是切到同一个配置重新编译设计时包或者干脆 Debug/Release 都编译输出。提示安装过程中若提示“无法找到 TMSBaseR.bpl”说明运行时包没有提前编译或者 IDE 的包搜索路径里找不到它。可以先在 Library 路径里加入上一步所有 .bpl 输出目录再重试安装。4. 避坑8.0.9.0 在 D7/DX10 下的高频翻车现场与排查套路4.1 现象包能编译但 IDE 启动报“访问违规”编译过程一切正常但 Delphi IDE 启动时弹出Access Violation at 0x...随后设计器无法打开窗体。原因通常是设计时包里的某个控件在 IDE 启动阶段执行了注册代码而这个注册代码调用了当前系统上不存在的 API或者是和 IDE 本身加载的另一个控件冲突。排查时先看异常地址发生在哪个模块把 IDE 的日志打开bds.exe /log或者查看 Windows 事件查看器定位崩溃模块是dclTMSXXX.bpl还是跟vclxxx.bpl相关。如果是 TMS 的包多数原因是版本的包文件与当前 IDE 版本有细微差异常见做法是把 IDE 关闭卸载刚才注册的设计时包删除所有 TMS 生成的.bpl、.dcp、.dcu文件重新用上一章的“最小编译命令”整套来一遍。4.2 现象DX10 下控件字体变成 9pt、看起来像老年机编译和安装都成功但拖到窗体上的 TMS 控件字体大小明显不对显示发虚。这个问题的本质是 8.0.9.0 这个版本在 DX10 上对DefaultFont的处理逻辑还停留在旧式假设——它把字体大小按 96 DPI 计算而 DX10 默认工程在 Win10 下经常开了高 DPI 感知Windows 会自动缩放字体造成控件字体看上去比设计时小或模糊。解决方法是修改项目里的TForm.Scaled属性并在FormCreate里对 TMS 控件做一次字体统一设置。如果你的项目不需要每台机器自适应更省事的是在 IDE 里把窗体Scaled设为 False同时在工程选项 版本信息里关闭“高 DPI 感知”让系统用标准 96 DPI 缩放来渲染。这个坑不会让程序跑不起来但会让界面看起来像上个世纪的作品。4.3 现象编译链接出现大量 E2199 / 重复符号当你把TMS 控件和自己的代码一起编译时编译器报出多个E2199重复符号错误或者某些单元出现 “Unit xxx was compiled with a different version of yyy” 的警告。这几乎都是因为你在某个全局搜索路径比如 IDE 的 Library 路径里加了多个 TMS 版本目录或者把 D7 和 DX10 的 .dcu 混放在同一个输出目录里。解决方法是回到 Library 路径配置保证只有一个版本目录在搜索路径里并且把不同版本编译产物分别放到带版本号的子目录例如Lib\D7、Lib\DX10。同时删除工程里Search Path中手填的无关第三方目录避免 IDE 拿到了别的包里的同名单元。4.4 现象设计时面板找不到 TMS 页签安装时提示成功但组件面板上没有 TMS 页签。这个我在 D7 上遇到过几次原因不是包没加载而是 Delphi 在安装包时写入注册表的控件类别记录和当前 IDE 的配置不匹配常见于系统里同时装了多个 Delphi 版本注册表串了。先确认设计时包真的被加载Component Install Packages列表里找到 TMS 的包看前面的勾选框是否为选中状态。如果已勾选但面板没有页签手动删除 IDE 注册表中当前版本缓存控件页签的键值路径类似于HKCU\Software\Embarcadero\BDS\{版本号}\Component Library删除后重启 IDE让它重新扫描所有已安装包并重建页签。D7 对应的是HKCU\Software\Borland\Delphi\7.0\Component Library。这个操作不会删除已安装的包只是让 IDE 重建缓存等于是给了后悔药。4.5 现象运行时 BPL 发布到客户机闪退开发机一切正常把编译好的 exe 连同 BPL 发布到客户环境启动就闪退。这类问题先分辨是缺 BPL 还是缺 DLL用Dependency Walker或Process Explorer检查进程加载模块如果缺少TMSBaseR.bpl程序会在启动阶段直接报“无法找到指定模块”而不是闪退真正闪退的情况更多是 BPL 版本和 exe 的编译版本不一致比如你用了 DX10.1 的 BPL 拷贝到了编译环境是 DX10.2 的机器上。解决思路很直接发布时从当前开发机编译输出目录抽取所有 TMS 相关的 BPL而不是随意从别人机器上拷贝如果客户机不允许安装单独的运行库干脆把 TMS 控件以静态链接形式编译进 exe在工程选项里把“运行时包”相关项清空去掉对 TMS 包的引用这样省去所有 BPL 部署问题。这是 Full Source 版本比试用版强太多的地方静态链接不违反授权而且 BPL 版本地狱的坑直接消失。5. 源码在手怎么用三个能立刻落地的定制技巧与验证方法5.1 技巧一给 TMS Grid 的默认字体写死为 Windows 标准值TMS Grid 系列控件在安装后默认字体总跟系统主题不一致尤其是中文环境下Tahoma 8pt显示很小用户看着费劲。既然拿到 Full Source就直接改源码一劳永逸。打开TMSAdvGrid.pas实际文件名取决于你用的控件常见是AdvGrid.pas或TMSGrid.pas找到构造函数Create里对Font的赋值逻辑比如constructor TAdvCustomGrid.Create(AOwner: TComponent); begin inherited Create(AOwner); Font.Name : Tahoma; Font.Size : 8; // 改成 9 或根据系统标准调整 end;改成Font.Name : Microsoft YaHei UI并把Font.Size : 9保存后再重新编译所有引用它的包。这里的关键是改了源码之后凡是依赖这个包的工程需要重新编译否则旧 .dcu 还在生效。5.2 技巧二改 TMS 源码里的私有方法直接加日志Full Source 的价值不只是改字体。当某个控件的显示逻辑有问题你想知道内部某个属性在运行时被谁改过而官方没有提供事件可以直接在源码的对应私有方法里加一行日志输出procedure TAdvGrid.UpdateScrollBars; begin // 自定义调试日志 OutputDebugString(PChar(Format(ScrollBar Max%d Pos%d, [ScrollBarMax, ScrollBarPos]))); // ...原始实现代码 end;注意不要改方法签名只加日志代码并注释写明日期和修改原因。这样再编译后用 Debug View 就能在运行时观察实际滚动条参数定位为什么用户说滚动条跳到奇怪的位置。这个方法不改控件的外部行为风险极小但要记得在调完后用源码回归一遍避免日志代码影响性能。5.3 验证方法用 DUnit 或简单的 ShowMessage 验证改动对源码改动最基础的验证是编译整个依赖链改动某个 .pas 后重新编译所有引用它的包和工程能过编译不报错算是过第一关。第二关是运行时验证在测试工程里放一个 TMS 控件跑起来确认改动生效且没有破坏其他功能。你可以用 DUnit 写一个集成测试用例检查控件字体属性是否符合预期procedure TTestTMSGrid.TestDefaultFont; var Grid: TAdvStringGrid; begin Grid : TAdvStringGrid.Create(nil); try CheckEquals(Microsoft YaHei UI, Grid.Font.Name); finally Grid.Free; end; end;这个测试用例会直接读取默认字体确保改动后的默认值不是靠视觉效果判断而是有断言支撑。如果你项目里没引入 DUnit简单方式是在窗体OnCreate里写ShowMessage(TAdvStringGrid.Create(nil).Font.Name)确认后释放这也是够用的验证手段。最后说个个人习惯我一般会在主项目交付前用 git diff 记录所有对 TMS 源码的改动然后把这些改动合并到一个单独的 patch 文件里随项目归档。这样升级到新版本组件时能把自定义补丁套回去不用二次追查改了哪几处省下的是大半天排查时间。希望帮到你。本文还有配套的精品资源点击获取