Raize控件适配Delphi 10.1 Berlin：修正版安装与配置指南

简介Raize 6.1.1.12 DX10.1 Berlin修正版为Delphi Berlin环境下的Raize组件库第三方修正包针对原版pas错误造成编译不成功的问题进行修复并预调好配置文件。使用者只需将压缩包解压至C:\Program Files\Raize\运行RC6\Source目录下的!Build_RC6.cmd即可完成组件编译安装亲测可用适合需要快速搭建Raize开发环境的中级Delphi开发者。资源包共956个文件、10.74MB涵盖202个hpp头文件、198个dcu编译单元、114个pas源文件、183个bmp位图及71个dfm窗体等包含头文件、编译单元、源码和界面资源便于开发时调用和参考。已有327人学习下载能直接获得修正后的组件库、安装脚本和配置说明省去手动排查与修改的时间是使用Raize 6的Delphi程序员值得收藏的资源。1. 这个修正版到底修了什么从一个失控的升级任务说起如果你手上的老项目还跑在 Raize 控件上又因为业务需要把开发环境从老 Delphi 一路迁到 10.1 Berlin大概率会在编译阶段就撞见三连找不到 BPL、DFM 里的类名对不上、运行起来整个窗口像被拆了一半。标题里的 Raize_6.1.1.12_DX10_1_Berlin_cocashu修正版就是一个针对 Delphi 10.1 Berlin 适配的 Raize 6.1.1.12 修正发行包DX10_1 是 Delphi XE10.1 的版本坐标后面的 cocashu 通常是做修正和发布动作的组织或个人标识。这篇文章就围绕这个版本号讲清三件事它到底修正了什么、怎么在 Berlin 上装干净、以及升级后要在哪些配置上做收尾避免让一次控件升级变成一个星期的加班。2. 先搞清 Raize 6.1.1.12 在 Berlin 下的兼容性底牌DX10_1 是版本坐标还是代号2.1 Raize 控件的演进为什么 6.x 会卡在 Berlin 这一代Raize 是我见过的最老牌的 VCL 第三方控件集之一。它提供的 TRzButton、TRzPanel、TRzTreeView、TRzToolbar 这些组件在 Delphi 6/7 时代几乎是界面工程的标准配置。它的特点不是酷炫而是“像原生的、比原生的更好用”按钮自带 HotTrackPanel 能直接画边框TreeView 的节点状态管理比 VCL 自带控件更顺手。所以很多从 2000 年初走过来的企业内部系统界面层大多积攒了大量 Raize 代码。问题出在 IDE 升级。Raize 6.x 的开发节奏并不快官方后续对 RAD Studio 新版本的支持也拖了很久。Delphi 10.1 Berlin 对应的 IDE 版本号是 22.x编译器从老的 Win32 模型到支持泛型、匿名方法、Unicode 字符串的完整重构运行时包RTL的链接方式和包版本规则全都变了。Raize 6.1.1.12 如果直接拿旧版的 .dpk 去开会出现两类典型错误一类是包内单元引用了老 RTL 里的符号另一类是设计期包和运行期包混合加载IDE 直接挂掉。所以你会发现网络上流传的 Raize 6.1.1.12 版本经常附带 DX10_1、Seattle、Berlin 这类后缀。这并不代表 Raize 有两个完全不同的产品线而是意味着有一批人把同一份 Raize 源码按不同 IDE 版本做了重新编译。这就是“修正版”存在的最直接原因官方没跟上社区补上。2.2 解析 DX10_1 这个后缀指向的编译器与运行时边界DX10_1 这个写法第一次看到时大概率会往 DirectX 10.1 上想但在 Delphi 控件打包命名的语境里它不是 DirectX 的意思而是“Delphi XE 10.1”的缩写。Delphi 10.1 Berlin 在正式发布时IDE 内部版本号是 22.0但由于 Embarcadero 从版本 10 开始采用年份式的命名大家写文件压缩包时为了简洁常常把 Delphi XE10.1 压缩成 DX10_1、D10.1、D101 这类短标签。标题里同时出现 DX10_1 和 Berlin等于双重确认了这个包对应的是 Delphi 10.1 Berlin而不是 Seattle 也不是 Tokyo。这个坐标非常重要因为 Delphi 的包绑定是“一个包只能在一个 IDE 版本里加载”。设计期包编译后会生成 .bplBPL 的文件名里往往带编译器版本号比如字符长度的后缀。如果你把一份给 Delphi 7 编译的 Raize 包强行拷进 Berlin 的 Bpl 目录IDE 加载时会出现“试图加载旧格式包”或“Package 文件版本不正确”的警告即使侥幸加载通过运行期也会在InitializePackage阶段抛出访问冲突。所以拿到标题里的 Raize_6.1.1.12_DX10_1_Berlin 时第一件事不是解压而是确认你本机装的确实是 Delphi 10.1 Berlin。判断方法很简单在 IDE 里打开 Help About看版本号是否为 22.0或者到命令行执行dcc32.exe -h看这版编译器的输出是否带Embarcadero Delphi for Win32 compiler version 22.0。如果本机是 10.2 Tokyo则停掉安装去找 DX10_2 或 Tokyo 的适配包。2.3 修正版一般改哪些文件DFM、BPL、pas 的三层适配所谓“cocashu修正版”本质上是一个针对原版 Raize 6.1.1.12 打过补丁的重新打包结果。按我拿到过的几个常见修正版来看改动通常落在三层工程定义文件、源代码文件、以及预编译好的二进制包。工程定义层主要改 .dpk 和 .dproj。Raize 的设计期包和运行期包是分开的原版工程文件里可能写了旧包的依赖关系比如requires旧版设计期包。修正版会把这些依赖改成 Berlin 对应的rtl、vcl、vclimg等基础包并更新包设置里的 LIB 路径防止编译时误引用了其他目录里的老 DCU。源代码层改的是几个兼容性点Raize 早期代码里使用了一些已经废弃的 Win32 API 隐式导入写法在 Berlin 的编译器下会变成警告甚至错误部分字符串类型需要从AnsiString显式切成UnicodeString。DFM 层则是处理窗体文件里的属性变化比如旧版 DFM 里Font.Charset DEFAULT_CHARSET的写法在 Berlin 的 Unicode 体系下有时会被 IDF 强制改写成GB2312_CHARSET从而导致中文乱码。所以“修正版”不是换了个图标重发了而是把这三个层面重新捏合了一次。你可以把它理解为一个“重新适配过的构建产物”。不要因为标题里有“修正”两个字就以为它是从某个不存在的官方补丁流出来的。它能帮你跳过最痛苦的编译期报错但运行期路径、DFM 版本、包加载顺序这些坑仍然需要你自己在项目里做配置。3. 把修正版装进 Delphi 10.1 Berlin最小安装脚本与手动补救3.1 安装前要备份的四个位置Reg、搜索路径、BPL目录、旧库Raize 这类控件安装最怕的不是装不上而是装到一半发现旧版本卸不干净。所以在我推荐你双击任何一个 .com 安装程序之前先把下面四个位置备份一遍。这是血泪经验不是形式主义。第一个是注册表里 IDE 的 Known Packages 项。Delphi 10.1 Berlin 的已知包列表存在HKCU\Software\Embarcadero\BDS\22.0\Known Packages下面里面记录了 IDE 启动时要加载哪些设计期包。如果之前装过老版 Raize这里会残留一条指向旧 BPL 的路径。第二次加载时会因为找不到文件而在 IDE 启动时立即弹红字。第二个位置是 IDE 的 Bpl 目录一般位于C:\Users\你的用户名\Documents\Embarcadero\Studio\22.0\Bpl。这个目录存放所有设计期和运行期的二进制包覆盖前最好先整体复制到别的盘。第三个位置是 Library 路径里所有指向 Raize 的目录。打开 IDE 的 Tools Options Environment Variables或者 Tools Options Delphi Options Library把Library Path里和 Raize 相关的条目记下来防止新版路径没加上、旧版路径还在第一位。第四个位置是老版本 DCU 文件。如果你之前使用过 Raize 5.x 或 6.0目录里往往散落着Rz*.dcu这些 DCU 不会自动失效会导致新包编译后被旧 DCU 覆盖。备份命令可以写成一个批处理放到待升级工程的同级目录。下面这段脚本的作用是导出注册表快照、复制 Bpl 和 Dcu 目录并在本地生成一个Raize_Backup.log来记录操作结果echo off set BDS22%APPDATA%\Embarcadero\BDS\22.0 set STUDIO%USERPROFILE%\Documents\Embarcadero\Studio\22.0 set BACKUP%USERPROFILE%\Documents\Raize_Backup_%date:~0,4%%date:~5,2%%date:~8,2% mkdir %BACKUP% rem 导出 Known Packages 注册表作为后悔药 reg export HKCU\Software\Embarcadero\BDS\22.0\Known Packages %BACKUP%\KnownPackages.reg /y rem 备份 IDE 默认 Bpl 和 Dcu 目录 robocopy %STUDIO%\Bpl %BACKUP%\Bpl /E /R:2 /W:2 robocopy %STUDIO%\Dcu %BACKUP%\Dcu /E /R:2 /W:2 rem 记录当前 Library 路径 reg query HKCU\Software\Embarcadero\BDS\22.0\Library /v Win32 %BACKUP%\LibraryPath_win32.txt echo 备份完成: %BACKUP% pause这段脚本里有几个参数值得说明。reg export的/y是强制覆盖同名文件避免备份过程停下来等待用户输入robocopy的/R:2 /W:2限制了单个文件失败时的重试次数为 2 次、每次等待 2 秒这样不会因为某个 BPL 被 IDE 占用而陷入无限重试。最后一条reg query只查了Win32这一条子键因为 32 位包的 Library 路径主要记录在这里。如果你装的是 64 位环境还要再查同名键下的Win64子键否则很容易漏掉。3.2 用命令行批处理注册 6.1.1.12 的步骤备份完成之后下一步就是安装修正版。最稳妥的方式还是用 IDE 来编译安装但为了避免过程中点错对话框我会先用一个批处理把二进制摆到正确位置再打开 IDE 做最后的“编译 Install”。假设你已经把Raize_6.1.1.12_DX10_1_Berlin_cocashu修正版解压到了D:\Components\Raize_6.1.1.12_DX10_1_Berlin并且解压目录下有Lib、Bpl、Source三个子目录。下面这段脚本做三件事复制预编译的 BPL 到 IDE 的 Bpl 目录、复制 DCU 到 Dcu 目录、把这个修正版的 Source 路径追加到全局 Library Path 里。注意它不会注册设计期包设计期包必须在 IDE 里手动安装echo off set COMP_ROOTD:\Components\Raize_6.1.1.12_DX10_1_Berlin set STUDIO%USERPROFILE%\Documents\Embarcadero\Studio\22.0 rem 1. 先复制 BPL 和 DCU xcopy %COMP_ROOT%\Bpl\*.bpl %STUDIO%\Bpl\ /D /Y xcopy %COMP_ROOT%\Lib\*.dcu %STUDIO%\Dcu\ /D /Y rem 2. 把 Raize 源码路径追加到 Library Path set LIBPATH_KEYHKCU\Software\Embarcadero\BDS\22.0\Library reg add %LIBPATH_KEY% /v Win32 /t REG_SZ /d %COMP_ROOT%\Source;%COMP_ROOT%\Lib;%STUDIO%\Dcu /f echo 文件复制完成。请打开 IDE按下面顺序安装设计期包。 echo 先编译 RaizeComponents_RT.dpk再安装 RaizeComponents_DT.dpk pause这里有个容易误解的参数/D /Y的/D是“只复制日期比目标新的文件”/Y是“不询问直接覆盖”。如果 BPL 目录下已经有一个老版本的RaizeComponents_RT.bpl而且日期比修正版还新那么/D会让复制失败。我一般会删掉这个/D直接强制覆盖因为同一个 IDE 版本下只需要保留一份 Raize。另外reg add那条命令把 Library Path 设置成了三个路径用分号分隔这个顺序很关键Source必须排在Lib前面否则源码和 DCU 混在一起时编译器会优先找到旧 DCU导致你改了源码却不生效。3.3 打开 IDE 后首次编译要盯的两个窗口命令行只完成了“放文件”真正让修正版生效的是 IDE 里的两步编译运行期包然后安装设计期包。打开 Delphi 10.1 Berlin选择 File Open Project定位到修正版 Source 目录下的RaizeComponents_RT.dpk点击编译。编译成功后再打开RaizeComponents_DT.dpk右键选择 Install。这一步如果顺利组件面板会出现 Raize 的分类。首次编译要盯两个窗口。第一个是 Message 窗口的 Compile 标签页里面会列出警告和错误。如果看到E2004或E2005说明在某个 .pas 文件里出现了旧语法修正版的源码应该已经处理过如果看到很多W1000 Symbol XXX is deprecated那是无害的不必管它。真正要盯的是有没有F2762这类“无法在已编译的包中重新链接”的错误这通常是因为 IDE 的 Dcu 目录里存在另一个版本的 Raize DCU。第二个窗口是Tools Packages里列出的包状态。正确安装后Raize 设计期包会显示为勾选状态它的输出文件路径应该指向D:\Components\Raize_6.1.1.12_DX10_1_Berlin\Bpl而不是系统默认目录。如果路径不对说明这个包没有从当前工程源编译而是加载了某个旧的已安装包。4. 运行期最容易出错的三个配置包选择、路径顺序和 DFM 版本4.1 在 Project Options 里锁定 Runtime/Design 包安装成功后真正使用 Raize 的项目还需要在 Project Options 里做一次“包锁定”。很多人的做法是在 IDE 面板上看到 Raize 就已经开心了直接写代码结果把项目拖到另一台机器上编译时IDE 报了“缺少 RaizeComponents_RT”。原因就是项目的 Runtime Packages 清单里没有勾选 Raize。打开 Project Options C Compiler/Delphi Compiler Packages找到Runtime packages这一栏。里面是一个用分号分隔的包名列表比如rtl;vcl;RaizeComponents_RT。如果没有RaizeComponents_RT点旁边的Add按钮从弹出的列表里勾选它。这一步的意义在于让项目显式依赖 Raize 运行时包而不是靠Uses代码里的隐式链接。对于设计期包不要把它加进运行时包列表因为设计期包只给 IDE 在设计器里使用分发时不需要带到最终 EXE 里。这里还有一个隐藏坑如果你同时安装了多个版本的 Raize比如 6.1.1.12 和 5.x运行时包列表里如果同时出现两个名字IDE 会以第一个为准。所以建议把修正版的RaizeComponents_RT手动移到列表最前面。具体做法是编辑文本框把它复制到分号前面的位置然后保存。4.2 设置 Library 路径的优先级避免引用到旧版 5.xLibrary Path 的优先级决定了编译器在Uses一个单元时到底去哪个目录找.dcu。默认情况下Delphi 会先找项目自身目录、再找 Library 全局路径。如果你的项目目录下有一份从旧系统拷过来的RzButton.dcu编译器会优先使用它忽略掉你在 Tools Options 里新加的 Raize 目录哪怕它的日期更新也没用。因为 DCU 存在即优先不会自动按目录顺序做时间戳比对。解决方法是把修正版 Lib 目录放到所有 Raize 旧路径的前面。在 Tools Options Delphi Options Library 的Library path框里把D:\Components\Raize_6.1.1.12_DX10_1_Berlin\Lib和D:\Components\Raize_6.1.1.12_DX10_1_Berlin\Source加到最前面。同时检查项目目录里的__history和__recovery子文件夹这些地方可能会残留旧版本 DCU 的副本建议在工程根目录下执行一次搜索把所有Rz*.dcu和Raize*.dcu手动清掉然后全量编译。判断路径优先级是否生效的办法是在 IDE 里打开一个用到 Raize 的单元按 CtrlClick 跳转到Raize的 Uses 声明。注意看 IDE 状态栏或代码编辑器的顶部路径提示是否显示为修正版 Source 目录下的文件。如果跳到的是另一个目录就说明你的Library path顺序有误或者项目文件里设置了额外的Search path。4.3 把 DFM 资源版本改到 Berlin 能接受的格式Raize 的控件属性很多在窗体保存时DFM 会记录这些属性。老项目从 Delphi 7 升级时DFM 文件有两类一类是文本格式可以直接打开另一类是二进制格式需要用 IDE 的Form Designer加载。Berlin 对文本 DFM 的兼容性很好但二进制 DFM 里如果带有 Raize 老版本的类名或属性在 IDE 打开窗体时会出现“Class TRzButton not found”或“Error reading XXXX: Property does not exist”。遇到这种问题先不要手动改 DFM。正确做法是用文本编辑器打开.dfm文件检查文件头是否包含object关键字。如果是二进制可以用一个外部转换工具或者用 IDE 的Convert命令。还有一个更快的复用办法新建一个空窗体把 Raize 控件拖上去保存一次生成一个新的Unit1.dfm然后从老窗体文件里复制object RLed这类对象定义到新 dfm 里。但注意属性值不能直接搬运比如Font.Charset在 Berlin 下可能默认变成了DEFAULT_CHARSET复制后会触发警告。对大多数项目来说最省力的路径是让 IDE 重新加载一次 DFM。当你第一次打开窗体时Berlin 会把老版本内容自动转换成新版本并在保存时写成当前格式。这个过程不要在有 Git 冲突时做因为 IDE 会在保存时重写整个文件导致 diff 爆炸。建议先把二进制 DFM 转成文本格式并提交再由 Berlin 做转换转换后逐个窗体检查布局。5. 升级到修正版路上的 5 个典型翻车现场现象、根因、解决5.1 现象IDE 启动就弹 Package 加载错误升级完成后很多人会发现重启 IDE 时立刻弹出红色错误框提示Cannot load package C:\...\RaizeComponents_DT.bpl系统找不到指定的文件。点确定后 IDE 能进但 Raize 的控件面板消失了。原因注册表里 Known Packages 记录的 BPL 路径还是旧版本的位置而这个位置已经被覆盖或删除。特别是当你先卸载了旧版本、再安装新版本时Windows Installer 会把注册表里所有指向旧路径的内容清掉但 BPL 文件本身还在更下一层的系统目录里残留。解决打开注册表编辑器定位到HKEY_CURRENT_USER\Software\Embarcadero\BDS\22.0\Known Packages在右侧列表里找到所有路径中包含Raize的字符串值双击查看其指向。把指向不存在文件的条目删除然后把当前修正版的 BPL 全路径补成新值。或者更干脆用第 3.1 节备份的 reg 文件恢复原来状态再重新安装一次。这个问题的根子在于 Windows 的包注册机制是只增不删而 IDE 启动时又按注册表顺序加载。5.2 现象打开窗体报 Class TRzButton not found打开老窗体时IDE 的 Form Designer 报Class TRzButton not found但工程能编译。原因是 DFM 中记录的TRzButton类在当前安装的包中不存在或者类名已经被改成了TRZButton。原因Raize 6.x 在设计时对类名的大小写和前缀有多次调整某些修正版可能是把设计期包里的控件名从TRzButton改成了TRZButton或者反过来。DFM 保存的是object RzButton1: TRzButtonIDE 反查时找不到完全匹配的符号就会报错。解决先看 DFM 里写的类名和当前安装包的类名差异。到 Source 目录搜一下TRzButton的 class declaration看看实际名称。然后用全局搜索把工程内所有.dfm里的TRzButton替换成正确名称。注意.pas文件里的对象声明也同步替换否则编译期会不一致。如果你不想修改 DFM可以在设计期包源码里加一个兼容类别名但那样会引入额外维护成本不建议长期保留。5.3 现象编译警告 E2264以及 C inline function在 Berlin 下编译一个以前能过的工程突然出现E2264或E2037这类错误并且错误位置指向 Raize 的.pas源文件。有些项目还会伴随C inline function提示。原因Berlin 的编译器和老版本相比对函数内联、常量折叠和 C ABI 的处理更严格。Raize 6.1.1.12 源码里遗留了一些在老编译器下被容忍的隐式转换比如把AnsiString直接传给UnicodeString参数或者调用一个在某种编译模式下不导出的内联函数。修正版一般已经处理过但如果你的工程启用了C mode或混合编译就会触发。解决检查 Project Options 里的 C 编译器设置确认没有开启Strict C inline之类的高级选项。对于纯 Delphi 工程把CodeGuard关掉再编译。如果错误仍然存在找到报错的.pas文件定位到具体的FOO(xxx)调用把参数强制转换成AnsiString或UnicodeString。这个坑往往会出现在同一份源码同时被多台机器编译时环境差异会放大它。5.4 现象运行期图标全是盾牌或者图标变模糊升级到修正版后Raize 控件上的自定义图标、按钮上的 ImageIndex 在运行期全部变成 Windows 默认盾牌图标甚至直接显示空白方框。原因Raize 某些控件使用了.res文件中的位图资源这些资源虽然在编译期被链接进去但如果你把Library path里的 Source 目录写错了资源文件会被编译器跳过导致程序使用了系统 fallback 图标。另一个常见原因是你在工程设置里删除了.res文件对 execution 资源的依赖比如改动了{$R *.res}引用。解决先确认 Source 目录下有没有RzButtons.res这类资源。然后在.dproj文件里搜索.res的引用方式。最稳妥的方法是在工程的.dpr里显式加入{$R *.res}并确保 DELPHI 项目文件所在的目录与.res文件的位置在同一个搜索路径下。其次检查最终 EXE 的大小如果从 20MB 变成 8MB大概率资源文件没进包。重新全量编译一次即可恢复。5.5 现象Debug 模式正常Release 模式启动闪退同一个工程用 Debug 配置能跑切到 Release 配置后一启动就闪退调用堆栈看不到 Raize 相关代码看起来像是 VCL 初始化阶段崩溃。原因这是 Raize 设计期包和运行期包在 Debug/Release 下使用不同 DCU 导致的典型症状。Raize 源码里某些全局变量可能被优化器折叠或者某些带{$IFDEF DEBUG}的断言代码在 Release 下被移除而你的工程部分单元仍强制引用了 Debug 版 Raize DCU。另一个更常见的场景是你只安装了修正版的 Debug 版 BPLRelease 版 BPL 还是旧版本。解决进入D:\Components\Raize_6.1.1.12_DX10_1_Berlin\Bpl查看有没有文件名带_D后缀的 Debug 包和没有后缀的 Release 包。在 IDE 里执行 Build 时Project Options 中的Runtime packages和Output path必须同时指向这同一个目录。如果只复制了 Debug 包到系统目录Release 包仍在别处就把两个版本的 BPL 都放到%STUDIO%\Bpl下并重新全量编译所有使用 Raize 的单元。这个现象最容易出现在“手动复制了编译好的包、而没有用 IDE 重新编译”的安装方式里。6. 用修正版给老界面做一次体检最小冒烟测试与升级后的收益6.1 写一个最小的 Raize 宿主 Form 来验证所有控件装完修正版后不要急着打开真实项目。先在一个新建的 VCL 工程里放一个 Raize 控件确认 IDE 和运行期都正常。下面这段代码放到一个空窗体的 FormCreate 里动态创建三个 Raize 控件只要它们能显示出来说明设计期包和运行期包都加载成功。procedure TForm1.FormCreate(Sender: TObject); var btn: TRzButton; pnl: TRzPanel; lbl: TRzLabel; begin pnl : TRzPanel.Create(nil); pnl.Parent : Self; pnl.SetBounds(10, 10, 300, 200); pnl.BorderOuter : fsGroove; pnl.Caption : Raize Panel OK; btn : TRzButton.Create(nil); btn.Parent : pnl; btn.SetBounds(20, 30, 100, 30); btn.Caption : Smoke Button; btn.HotTrack : True; lbl : TRzLabel.Create(nil); lbl.Parent : pnl; lbl.SetBounds(20, 80, 200, 20); lbl.Caption : If you see this, Raize is alive.; end;这段代码里的关键点在两个地方btn.Parent : pnl让按钮成为面板的子控件验证的是 Raize 控件之间的父子关系是否正常btn.HotTrack : True验证的是 Raize 自定义属性能不能被赋上如果设计期包有问题这个属性会编译过不去。运行时如果窗口上出现一个带内凹边框的面板、一个高亮按钮和一个标签就说明基础链路是通的。6.2 用工具检查控件是否真的由 Raize 渲染光显示出来还不够。因为 Raize 本身是基于 VCL 标准控件封装它会在父级窗口上自绘所以有时候你会看到“好像生效了但其实就是普通标准控件”。验证方法是借助 Windows 的 Spy或者 Visual Studio 的 Spyxx来查看窗口类名。打开 Spy用 Find Window 工具点击窗体上的按钮查看Window Class。Raize 的自绘按钮通常会使用TRAzButton这个窗口类名以你编译的单元名称为准而原生 VCL 按钮是TButton。如果类名是TButton说明你的代码虽然写的是TRzButton但 IDE 在后台还是用了旧控件的别名这时要回到第 4.2 节去检查路径顺序可能有某个旧 DCU 在生效。这一项检查对存量项目特别有用。它可以帮你确认整个项目里到底是哪些窗口真的跑在 Raize 绘制逻辑上哪些窗口因为 DFM 兼容问题而静默降级成了标准控件。6.3 把升级经验固化成团队的检查清单最后给你一张我每次升级 Raize 都会过的检查清单。第一确认 IDE 版本号是 22.0第二确认全局Library path只保留一个 Raize 目录第三确认项目的Runtime packages里包含RaizeComponents_RT第四逐个窗体搜索.dfm中的object XXX: TRz确保类名和实际安装一致第五在 Release 配置下全量编译并启动一次检查图标资源是否在。这次升级之后我最大的教训是永远不要跳过“先备份 Known Packages”这一步。因为 Raize 的包依赖关系比普通控件复杂设计期包和运行期包一旦版本错位IDE 会在极端糟糕的时候才告诉你真相比如你着急给客户出包的那天。希望你在 Berlin 上的这次 Raize 升级不要变成一个周末的加班希望帮到你。本文还有配套的精品资源点击获取