简介这是一份专为 Delphi 开发者打造的完整组件源码资源对应 TMS Component Pack 8.0.9.0完整支持 Delphi 7 至 DX10 版本适合需要在 VCL 与 FireMonkey 框架下快速构建桌面应用的中高级开发者。包内收录了超过 250 种控件及对应源码覆盖界面 UI、数据库访问、图表报表、网络通信等常用领域例如高级网格、表格、Office 风格对话框、工具栏、HTTP 客户端、Web 浏览器等可帮助开发者减少重复造轮子并通过对源码的研读与修改实现深度定制。整套源码压缩包约 36.71MB并附带详尽开发文档便于查阅组件属性、事件与方法。目前已有 210 人学习无论用于企业级项目快速交付还是作为学习组件化开发原理的参考都非常值得拥有一份。1. TMS Component Pack 8.0.9.0 Full Source for D7-DX10 是给谁用的TMS Component Pack 8.0.9.0 Full Source for D7-DX10一句话说是一个 Delphi 第三方控件全家桶的完整源码包同时覆盖 Delphi 7 和 Delphi 10.x 两代 IDE。跨这两代不是小工程D7 还是 ANSI 字符串和 32 位时代的编译器到 DX10 时字符串早已变成 Unicode、目标平台也加上了 64 位这套包把兼容逻辑写在了同一份源码里。它和安装器版本的最大区别是「Full Source」四个字你可以自己重新编译所有包IDE 崩溃后能打开控件源码直接定位迁到新 Delphi 时还能手改不兼容片段。它最适合谁的场景老项目还在 D7 上、准备迁到新版本 Delphi 但又不想换掉 TMS 控件的团队以及想从成熟第三方控件里学跨版本兼容写法的开发者。2. 读源码包目录D7 与 DX10 的兼容套路先从文件后缀看穿拿到 8.0.9.0 这类源码包的压缩包后别急着开 IDE先把目录结构过一遍。这一步能省掉后面一半的玄学排错。我习惯直接在命令行里拉一份目录树。find . -maxdepth 2 -type d | sort常见的布局是packages、source、units、demos四类目录并存但不同压缩包的组织方式不完全一样。source下是控件的.pas源码packages下是承载编译入口的包工程文件units是预编译好的.dcudemos是官方示例工程。搞清楚各自职责后配置搜索路径时就不会把四个目录全塞进去——那样只会拖慢编译并引入大量重名单元冲突。2.1 目录各管什么packages、source、units、demos 别混装packages是整个安装流程的核心里面放的是.dpk和.dproj这类包描述文件。source里的.pas按组件族分目录比如编辑框类、网格类、工具栏类、日历类每个子目录对应一批功能近似的单元。units通常是带正确编译选项编译好的.dcu理论上有它就能免编译直接装包但既然是 Full Source 版我一般不会依赖这份 dcu宁愿自己从源文件全量编一遍——因为你无法知道这份 dcu 是用哪个 IDE 版本、打开了哪些条件编译符号编出来的。demos目录往往被初学者忽略但其实它比 README 更可靠。源码包对应的编译选项、运行时包和设计时包的组合方式都可以通过打开一个 demo 工程然后按 F9 验证。所以我的建议是先看目录再看 demo最后才动手编译包。2.2 一个 String 引发的跨代差异UNICODE 条件编译D7 和 DX10 之间的鸿沟表面上是一堆编译错误根子上只有一个字符串类型变了。D7 里String默认是AnsiString按字节存、按代码页解释Delphi 2009 之后String变成UnicodeString按 UTF-16 编码单元存。TMS 8.0.9.0 的源码要同时支持两代最常见的写法就是用UNICODE条件编译区分指针和转换逻辑。// 第三方源码中常见的跨版本写法 {$IFDEF UNICODE} P : PChar(S); // DX10 下 PChar 是 PWideChar {$ELSE} P : PAnsiChar(S); // D7 下 PChar 本来就是 PAnsiChar {$ENDIF}这段逻辑说明一个关键差异在 D7 里直接写PChar(S)不会出问题但同样的代码放到 DX10 会让语义从「指向单个 ANSI 字符」变成「指向单个 UTF-16 字符」。如果你的工程里还有大量PChar做字节扫描的旧代码迁移后拿到的不只是警告而是实打实的缓冲区越界。遇到这类源码我一般会优先把它改成上面这种显式分支而不是全局搜索替换。2.3 文件后缀才是真正的版本地图.dpk 与 .dproj同一套源码要同时喂给 D7 和 DX10文件后缀本身就是最好的路标。下表是我拿到源码包后第一眼对照的信息后缀用途适合的 IDE.dpkDelphi 包工程文本格式D7 到 XE 的老版本 IDE.dprojXML 包工程含平台和配置Delphi 2007 之后的 IDE.dcu编译产物Delphi 单元运行时按目标平台匹配.bpl包二进制最终加载到 IDE运行时包与设计时包都走它.res包资源版本信息在里面编译时自动生成在 8.0.9.0 这类跨版本包里packages目录通常会同时出现.dpk和.dproj也可能只有.dpk需要新版 IDE 打开时自动转换。转换本身不可怕可怕的是你把老.dpk删了——D7 那边还没编完就再也编不回去了。正确做法是让新版 IDE 另存或转换出新.dproj老文件原样留在目录里两边各编各的。2.4 识别包依赖先编哪个不靠试多包源码最头疼的是编译顺序。TMS 这种全家桶里网格包可能依赖核心包工具栏包又依赖基础类型包顺序错了就会报File not found: xxx.dcu。与其一个个试不如直接把.dpk文件的requires段拉出来看。grep -i ^requires packages/*.dpk | sed s/[,;]/ /g这条命令会把每个包想依赖的邻居列出来依赖最少的包就是编译起点。实际执行时注意大小写和缩进requires不一定是行首也可以在 IDE 里打开包工程看 Projects 窗口里列出的 Requires。按依赖关系从底层往上层编比按文件名排序编可靠得多这是我从第一次装多包控件就留下的习惯。3. 在 D7 上把它装好编译顺序、库路径与设计时包D7 是 2002 年的编译器但它至今仍服务大量老项目。把 TMS 8.0.9.0 装进 D7本质上要做三件事把运行时包按依赖顺序编出来、把搜索路径配到让 IDE 找得着单元、把设计时包注册进 IDE 的组件面板。顺序一乱后一件事会以极其难看的姿态报错。3.1 先装运行时包再装设计时包一次搞清顺序运行时包是功能本体设计时包只是让 IDE 把这些功能搬到组件面板上的壳。IDE 加载设计时包时会隐式加载它依赖的运行时包如果运行时包还没编出来或不在系统搜索路径里IDE 会直接拒绝启动或弹 Access Violation。所以第一步永远是编译运行时包。echo off set DCCC:\Delphi7\Bin\dcc32.exe set SRCD:\TMS8\packages cd /d %SRC% %DCC% -B -LN -U%SRC% CorePackage.dpk %DCC% -B -LN -U%SRC% GridPackage.dpk %DCC% -B -LN -U%SRC% ToolbarPackage.dpk这里三个参数各有讲究-B是强制全量重编防止上次残留的.dcu干扰结果-LN让编译器只输出.bpl和.dcp不把.dcu撒进源码目录污染搜索路径-U指定临时的单元搜索路径让编译器在编译包的过程中找到依赖单元。包名按你目录里的实际文件名替换依赖关系参考 2.4 节列出的requires清单从底层往上层执行。3.2 Library Path 该加哪几层source 和 units不是 packagesD7 的Tools Environment Options Library Library Path是全局生效的搜索路径影响所有工程。这里最常见的错误是把packages目录加进去——它只放包工程文件不包含.pas加了等于没加。真正需要加的是source和预编译好的units两层。REM 命令行编译时的等效配置IDE 里就填这串路径 set TMSD:\TMS8 %DCC% -B -U%TMS%\source;%TMS%\units CorePackage.dpk分号分隔的多路径有先后顺序排在前面的路径优先被解析。如果你曾手工改过源码或遇到同名单元时有选择困难把改动过的源码目录放到最前面能少踩很多「我改了但没编进去」的翻车现场。在 IDE 里填路径时同样按这个顺序source在前、units在后demos永远不加。3.3 注册设计时包组件面板里认名字不认文件运行时包编好后打开Component Install Packages Add选中对应的设计时.bpl组件面板上就该出现 TMS 各组件的子页了。但「该出现」和「真出现」之间还隔着一层判断怎么知道手上这份 bpl 到底是不是设计时包用 tdump 查看导出符号最快。C:\Delphi7\Bin\tdump.exe -e D:\TMS8\packages\DesignTime.bpl | findstr /i Registertdump是 Delphi 自带的二进制解析工具-e参数列出导出符号。如果输出里有Register字样说明它包含组件注册逻辑装进 IDE 会出现在组件面板上如果什么都没有它只是运行时包装了也不会在面板里生成任何图标。我见过不少卡在「装了没用」的人基本都是因为 Add 错了文件。3.4 D7 编译选项别让 Range Checking 咬住第三方源码给 D7 配搜索路径时顺手把工程选项也看一眼。老项目里很多人习惯打开Range Checking和Overflow Checking这些选项对自家代码是好事但第三方控件没按你的严格级别测试过全量打开后可能编译出一个此前从未出现过的下界错误。{$RANGECHECK OFF} {$OVERFLOWCHECKS OFF}在调用 TMS 控件的主工程头部临时关掉这两项能避免把第三方源码里合法的边界操作误判成崩溃。等控件编译稳定后再按项目要求逐模块打开。这是我踩过一次List index out of bounds后才学会的防御姿势。4. 迁到 DX10Unicode、64 位与 dproj 三个硬门槛D7 装好后真正的大头在把同一套源码搬到 DX10。DX10 这一代 IDE 从编译入口到运行时模型都换了工程文件用 XML 格式的.dproj字符串全局 Unicode目标平台不再默认只出 32 位。这三个门槛挨个处理迁移才可能顺畅。4.1 别用 D7 的 dpk 直接开新 IDE先找 dproj 或做一次转换在 DX10 里打开.dpk会触发版本转换但我不建议直接拿老.dpk当入口。常见的做法是先把packages目录里的.dproj找出来或用 IDE 的 Open 命令选.dpk让它生成新格式转换后立刻另存为独立文件别覆盖原文件。call C:\Program Files (x86)\Embarcadero\Studio\20.0\bin\rsvars.bat MSBuild.exe TMSCompPack.dproj /p:ConfigDebug /p:PlatformWin32 /t:Rebuildrsvars.bat是 Embarcadero 装在系统里的环境变量批处理执行后MSBuild才能找到对应版本的编译器和库目录。/p:ConfigDebug决定条件编译符号里有无DEBUG/p:PlatformWin32指定目标平台/t:Rebuild等价于先清理再编译。如果本机只装了 DX10 而没装 D7打开.dproj时也不会碰到老工程转换的兼容问题。4.2 Unicode 从名词变成编译错误String / PChar / AnsiString 怎么处理源码搬到 DX10 后第一波编译错误会集中在字符串和指针的混用上。PChar在 D7 里默认就是单字节字符指针到了 DX10 变成宽字符指针任何把PChar当作PAnsiChar传给 Windows API 的代码都会被编译器拒绝。procedure SetTextFromBuf(const ABuf: PAnsiChar); var S: string; begin {$IFDEF UNICODE} S : UTF8ToUnicodeString(ABuf); // UTF-8 进UnicodeString 出 {$ELSE} S : ABuf; // D7 下 PAnsiChar 可直接转 AnsiString {$ENDIF} end;这段代码展示了迁移时最常见的修法先把外部数据明确声明成PAnsiChar或PWideChar再做转换而不是依赖默认的PChar。如果第三方源码里这类调用很多迁移策略是「先保编译通过再谈行为一致」——把每个模糊的PChar改成显式的PAnsiChar让编译器不再有歧义。4.3 64 位设计时包和运行时包必须分开编DX10 的 IDE 进程是 32 位的设计时包永远只能编 Win32但应用程序的运行时包可以编 Win64。这意味着同一份 TMS 源码在 DX10 下至少要编两次一次 Win32 给 IDE 加载一次 Win64 给最终程序链接。两次的输出目录必须分开否则.dcu互相覆盖IDE 加载和程序编译会随机出错。type {$IFDEF CPUX64} THandleValue NativeUInt; {$ELSE} THandleValue LongWord; {$ENDIF}控件源码里凡是保存句柄、指针地址的字段在 64 位下都必须扩容到NativeUInt。旧源码里用Integer存HWND的做法在 Win32 下没毛病但 Win64 下指针是 64 位截断到 32 位整数会直接丢地址。遇到这类代码不要全局替换成Int64用NativeUInt更贴近指针语义也避免无谓的符号扩展问题。4.4 编译成功但版本错乱bpl 同名覆盖是隐藏雷新 IDE 和老 IDE 编出的.bpl如果同名很容易互相覆盖。你今天用 DX10 编了TMSGrid.bpl明天切回 D7 又编同名文件两个文件都叫TMSGrid.bpl但包含的编译器版本和包版本完全不同。IDE 加载时会看到版本不对齐的包弹出一串指向不明的错误。C:\Program Files (x86)\Embarcadero\Studio\20.0\bin\tdump.exe -e TMSGrid.bpl | findstr /i version编完后用 tdump 查看包版本资源确认这份 bpl 属于当前 IDE再做注册。我一般会把不同 IDE 的编译输出分别放到独立目录比如output\D7和output\DX10从根本上杜绝同名覆盖。这比每次安装前肉眼确认文件名更保险。5. 排障现场8.0.9.0 源码包安装迁移的 5 个高频坑这部分是我从实际部署里攒下来的血泪经验每条都按「现象 → 原因 → 解决」写遇到同款问题可以直接照做。5.1 D7 编译报 File not found: Controls.dcu现象任意包编译到一半弹File not found: Controls.dcu和 TMS 本身无关。原因编译器的单元搜索路径里没有 D7 自带的 VCL 库目录最常见于用命令行dcc32编译时只写了-UTMS 路径没带 Delphi 自身目录。解决在-U参数里把C:\Delphi7\Lib加进去IDE 用户则在 Library Path 里补这一项。这个目录不对后续所有标准控件都无法解析属于先决条件。5.2 设计时包装上后 D7 启动闪退现象注册设计时包后重启 IDE启动画面一闪而过或弹 Access Violation随后进程退出。原因运行时包没有被正确安装到系统搜索路径IDE 加载设计时包时找不到依赖的.bpl直接崩溃。很多时候是编译顺序错乱造成的依赖缺失。解决删掉刚装的设计时包注册项回到 3.1 节把运行时包按requires顺序全部编完并确认存在再重新加载设计时包。推荐先tdump查看设计时包的依赖文件名再去系统目录确认对应 bpl 真的存在。5.3 DX10 打开源码报 E2256 Illegal character 或中文注释乱码现象新 IDE 打开.pas文件代码里的中文注释变成乱码编译直接报非法字符。原因源码文件是 ANSI/GBK 编码DX10 的编辑器默认按 UTF-8 或系统 Unicode 代码页解析编码对不上就乱。这批文件通常是在老机器上保存过的历史版本。解决用 Notepad 或 IDE 自身的 Save As 菜单把报错文件批量转换为 UTF-8 with BOM 再编译。转换前先确认完整源码包没有多处重复——如果只有个别文件乱很可能改过文件而非整包问题。5.4 组件面板装了但看不到控件现象Install Packages 列表里能看到新包但组件面板翻遍所有页签都不见 TMS 条目。原因Add 进去的是运行时包不是设计时包。运行时包没有Register过程不会向 IDE 注册任何组件。解决用 3.3 节的 tdump 命令检查 bpl 导出符号确认有Register。如果确实没有到packages目录找带 Design/DesignTime 字样的包工程重新编译。这个坑在 Full Source 版里尤其常见因为压缩包里同时存在两类包文件名长得几乎一样。5.5 64 位运行时包链接报外部错误现象Win64 下编译应用出现无法定位的单元或函数而 Win32 编译一切正常。原因只为 Win32 编了运行时包64 位构建时链接器找不到对应的.dcu和.bpl或者 32 位与 64 位的.dcu混在了同一个输出目录里互相踩踏。解决用MSBuild的/p:PlatformWin64单独重编一次运行时包输出目录和 Win32 分开。可以让 TMS 源码包的构建脚本把 DCU 输出按平台名组织避免下次再混合。6. 验证 Full Source 是否真正可用的最小工程与回归习惯源码包装完验证比信任重要。我的做法是建一个最小冒烟工程把每个组件族的代表性控件各放一个到表单上再编译一次网格放TAdvStringGrid或TAdvColumnGrid一类、编辑框放 TMS 的编辑控件、工具栏放一个TAdvToolBar。能用最小工程跑起来才能说明编译顺序、库路径和设计时包三层都通了接下来才是完整迁移。program TMSMinSmoke; uses Vcl.Forms, MainForm in MainForm.pas {Form1}; {$R *.res} begin Application.Initialize; Application.MainFormOnTaskbar : True; Application.CreateForm(TForm1, Form1); Application.Run; end.这个工程同时保持 D7 和 DX10 两个副本一个用.dpr走老编译链一个放在.dproj里走新编译链。两个副本共用一个业务代码目录但各自维护工程文件。日常改动后用批处理把两个版本都编一遍来回归。call build-d7.bat call build-dx10.bat回归脚本最后一个动作是把编译退出码写进日志。我习惯把%ERRORLEVEL%追加到log.txt一旦某天 D7 编过而 DX10 编不过日志立刻能指出是哪一侧挂了不用开着两个 IDE 来回对比。每次升级 TMS 或切换 Delphi 版本我都会先跑一遍这两个冒烟工程确认通过后才动业务代码。这套源码包能不能用、值不值得继续投入用最小工程验证比读 README 直观得多也是我劝身边人拿到 Full Source 后一定要做的第一件事。希望帮到你。本文还有配套的精品资源点击获取