简介Raize_6.1.1.12_DX10_1_Berlin_cocashu修正版面向使用Delphi/CBuilder Berlin10.1进行VCL界面开发的程序员尤其适合需要Raize组件库但受编译报错困扰的中高级开发者。该版本针对原包中pas文件错误导致编译不通过的问题做了修正并已调整配置文件解压至C:\Program Files\Raize\后执行RC6\Source目录下的!Build_RC6.cmd即可完成构建省去自行排查源码错误的时间。压缩包共956个文件约10.74MB以hpp头文件、dcu编译单元、bmp位图、pas源码、dfm窗体文件、res资源及inc、dpk、bpl等包文件为主覆盖源码、资源与安装脚本结构完整。已有329人学习下载。对于正在搭建Raize开发环境或需要修复旧版编译问题的读者可直接获得可用的组件源码与构建脚本快速恢复项目编译并参考其目录组织方式理解组件库的模块划分。1. 从一份“修正版”控件包说起Raize 6.1.1.12 在 Berlin 上的真实定位如果你最近在维护一套 Delphi 10.2 TokyoBerlin时期的老项目大概率会在某个时刻撞上 Raize Components 这个控件包。标题里的Raize_6.1.1.12_DX10_1_Berlin_cocashu修正版拆开看就是四层信息控件包版本 6.1.1.12、目标 IDE 是 DX10.1Delphi 10.2 Tokyo代号 Berlin、带 DX10 编译支持、以及一份社区流传的“修正版”。它解决的核心问题很具体——原版安装包在新版 IDE 下编译报错、设计期包加载失败、部分控件在 VCL 高 DPI 下渲染异常。适合谁正在维护 Berlin 及以上版本 Delphi 项目、又不想推倒重来换控件的团队。这一章先把“它是什么、为什么会有修正版”讲清楚后面几章再落到安装、编译、排错和参数调优。2. 修正版到底修了什么从包结构到编译链的拆解2.1 原版在 Berlin 上翻车的三个典型位置Raize Components 6.1.1.12 发布时官方主要覆盖到 Delphi 10.1 及更早版本。到了 BerlinIDE 的包编译规则、单元作用域、以及Winapi前缀的强制要求都变了。原版直接安装通常会在三个地方卡住第一DesignIntf、DesignEditors这类设计期单元没有加Winapi或Vcl前缀Berlin 的编译器会直接报Unit not found。第二运行时包Runtime Package和设计期包Design Package的requires列表里仍然写着rtl、vcl这种旧式短名Berlin 要求写成rtl、vcl的同时还要匹配对应的lib路径。第三部分控件的Register过程里引用了已经废弃的DsgnIntf导致设计期包能编译但无法注册到工具面板。修正版的做法不是重写控件而是把这三类“接口层”问题批量替换掉。常见做法是用脚本扫描所有.pas文件把DesignIntf替换为Winapi.DesignIntf或按实际单元路径调整把DsgnIntf替换为DesignIntf再手动调整.dpk里的requires和contains顺序。2.2 包文件清单与编译顺序一个完整的 Raize 修正版包目录通常包含以下文件。不同来源的包可能略有增减但核心结构一致文件/目录作用是否必须RaizeComponentsRun.dpk运行时包包含所有控件单元是RaizeComponentsDsgn.dpk设计期包注册控件到工具面板是Source/所有.pas源码是Lib/预编译的.dcu或.obj否建议删掉重编Resources/控件用到的图标、位图资源是RaizeComponentsRun.dprojBerlin 项目文件建议有编译顺序必须是先编译RaizeComponentsRun.dpk再编译RaizeComponentsDsgn.dpk。如果顺序反了设计期包会因为找不到运行时包的符号而报Unsatisfied forward or external declaration。2.3 用命令行批量修正单元引用如果你拿到的修正版仍然有零散的单元引用问题可以用下面这个 Python 脚本做一次全量扫描和替换。脚本只处理.pas和.dpk文件替换规则写在字典里方便你按实际路径调整。import os import re # 替换规则旧单元名 - 新单元名 REPLACE_MAP { r\bDesignIntf\b: Winapi.DesignIntf, r\bDesignEditors\b: Winapi.DesignEditors, r\bDsgnIntf\b: DesignIntf, r\bToolsAPI\b: ToolsAPI, # 保持不变但确保不被误替换 } # 需要扫描的扩展名 EXTS (.pas, .dpk, .dpr) def fix_file(filepath): with open(filepath, r, encodingutf-8, errorsignore) as f: content f.read() original content for pattern, replacement in REPLACE_MAP.items(): content re.sub(pattern, replacement, content) if content ! original: with open(filepath, w, encodingutf-8) as f: f.write(content) print(f[FIXED] {filepath}) else: print(f[SKIP] {filepath}) def walk_and_fix(root_dir): for dirpath, _, filenames in os.walk(root_dir): for name in filenames: if name.lower().endswith(EXTS): fix_file(os.path.join(dirpath, name)) if __name__ __main__: # 把这里改成你的 Raize 源码根目录 walk_and_fix(rD:\Components\Raize\Source)逻辑说明REPLACE_MAP里的正则用了\b单词边界避免把MyDesignIntfHelper这种自定义单元误伤。errorsignore是为了兼容老文件里可能存在的非 UTF-8 字符。跑完脚本后不要急着编译先用 IDE 的“项目”菜单打开.dpk看Contains列表里有没有重复项或缺失项。参数说明如果你用的是 Berlin 的默认库路径Winapi.DesignIntf对应的实际文件在C:\Program Files (x86)\Embarcadero\Studio\19.0\source\ToolsAPI下。如果这个路径不存在说明你的 IDE 安装不完整需要先修复安装。3. 在 Berlin 里把修正版装进 IDE从编译到工具面板3.1 编译运行时包的最小命令Berlin 自带的dcc32命令行编译器可以直接用来验证包是否能过编译。假设你的 Raize 源码在D:\Components\Raize\Source输出目录设为D:\Components\Raize\Lib命令如下# 先创建输出目录 mkdir D:\Components\Raize\Lib # 编译运行时包 C:\Program Files (x86)\Embarcadero\Studio\19.0\bin\dcc32.exe ^ -B ^ -Q ^ -W ^ -$D -$L -$O ^ -ID:\Components\Raize\Source ^ -ND:\Components\Raize\Lib ^ -ED:\Components\Raize\Lib ^ D:\Components\Raize\Source\RaizeComponentsRun.dpk参数逐个说-B强制全部重编译避免旧.dcu干扰-Q安静模式只输出警告和错误-W把警告当错误提前暴露隐患-$D开调试信息-$L开局部符号-$O开优化。-I是单元搜索路径-N是.dcu输出路径-E是可执行文件输出路径。如果编译报F1026 File not found: Winapi.DesignIntf.dcu说明你的 IDE 库路径没配好需要在dcc32的-I里追加C:\Program Files (x86)\Embarcadero\Studio\19.0\source\ToolsAPI。3.2 设计期包的注册与工具面板加载运行时包编译通过后设计期包的编译命令几乎一样只改文件名C:\Program Files (x86)\Embarcadero\Studio\19.0\bin\dcc32.exe ^ -B -Q -W ^ -$D -$L -$O ^ -ID:\Components\Raize\Source ^ -ND:\Components\Raize\Lib ^ -ED:\Components\Raize\Lib ^ D:\Components\Raize\Source\RaizeComponentsDsgn.dpk编译成功后打开 Berlin走Component - Install Packages - Add选中RaizeComponentsDsgn.bpl。如果工具面板没出现 Raize 页签先检查RaizeComponentsDsgn.dpk的Register过程是否被正确导出。常见做法是在.dpk末尾加一行Exports声明但 Berlin 下更推荐用procedure Register;的标准写法不要手动Exports。3.3 验证控件是否真正可用装完之后不要只看着工具面板有图标就以为成了。新建一个 VCL 应用拖一个RzButton到窗体上然后做三件事第一按 F12 在设计期和代码期之间切换看是否报Class not registered第二编译运行看运行时是否报Package RaizeComponentsRun.bpl not found第三打开窗体设计器的Object Inspector看RzButton的属性是否完整显示。这三步都过了才算真正装好。提示如果运行时提示找不到.bpl把D:\Components\Raize\Lib加到系统PATH环境变量里或者在项目选项的Debugger里设置Host Application的附加库路径。4. 避坑与排查修正版安装中最容易翻车的五个点4.1 编译时报“单元重复”或“找不到 .dcu”现象dcc32报E2004 Identifier redeclared或F2063 Could not compile used unit。原因源码目录里混入了旧版本残留的.dcu或者Lib目录同时存在多个版本的编译产物。解决删掉Source和Lib下所有.dcu、.o、.bpl只保留.pas和.dpk然后重新编译。我一般会在编译前跑一句del /s /q D:\Components\Raize\*.dcu省得玄学问题。4.2 设计期包能编译但工具面板不显示现象RaizeComponentsDsgn.bpl编译成功Install Packages里也加了但工具面板没有 Raize 页签。原因Register过程里调用了RegisterComponents但传入的页签名和已有页签冲突或者Register过程没有被正确链接。解决打开RaizeComponentsDsgn.dpk确认Register单元在contains列表里并且Register过程里RegisterComponents(Raize, [...])的页签名没有和别的控件包重名。如果重名改成Raize2或RaizeX再试。4.3 高 DPI 下控件模糊或错位现象在 4K 显示器上RzButton、RzEdit的文字和边框发虚或者窗体缩放后控件位置偏移。原因Raize 6.1.1.12 的控件大部分没有实现WM_DPICHANGED消息处理Berlin 的 VCL 高 DPI 支持需要控件自己响应。解决在项目主窗体里手动设置Scaled为True并在FormCreate里调用ChangeScale。更彻底的做法是给每个 Raize 控件套一层TPanel用Align和Margins做布局避免直接依赖控件的绝对坐标。4.4 运行时包版本冲突现象程序启动时报Cannot load package RaizeComponentsRun. It contains unit RzCommon, which is also contained in package xxx。原因项目里同时引用了另一个也包含RzCommon的包或者 Raize 的运行时包被编译了两次。解决在项目选项的Packages里只保留一个RaizeComponentsRun把其他同名或包含同名单元的包移除。如果用的是Runtime Packages模式确保RaizeComponentsRun.bpl的版本号和设计期包一致。4.5 修正版源码里的“隐藏依赖”现象编译时报F1026 File not found: RzBorder.pas但文件明明在Source目录里。原因.dpk的contains列表里写的是相对路径而dcc32的工作目录不对。解决把dcc32的当前目录切到Source所在目录或者在contains里写全路径。我一般会在.dpk里把所有contains改成Source\RzBorder.pas这种相对路径然后用-I指定根目录这样最稳。5. 进阶把 Raize 修正版做成可复用的编译脚本与版本管理5.1 用批处理封装编译流程每次手动敲dcc32命令太累而且容易漏参数。我一般会写一个build_raize.bat放在 Raize 根目录下内容如下echo off setlocal set IDE_PATHC:\Program Files (x86)\Embarcadero\Studio\19.0 set RAize_ROOT%~dp0 set SRC%RAIZE_ROOT%Source set LIB%RAIZE_ROOT%Lib if not exist %LIB% mkdir %LIB% echo [1/3] 清理旧编译产物... del /s /q %SRC%\*.dcu nul 21 del /s /q %LIB%\*.dcu nul 21 del /s /q %LIB%\*.bpl nul 21 echo [2/3] 编译运行时包... %IDE_PATH%\bin\dcc32.exe -B -Q -W -$D -$L -$O ^ -I%SRC% -N%LIB% -E%LIB% ^ %SRC%\RaizeComponentsRun.dpk if errorlevel 1 goto :fail echo [3/3] 编译设计期包... %IDE_PATH%\bin\dcc32.exe -B -Q -W -$D -$L -$O ^ -I%SRC% -N%LIB% -E%LIB% ^ %SRC%\RaizeComponentsDsgn.dpk if errorlevel 1 goto :fail echo 编译完成输出在 %LIB% goto :eof :fail echo 编译失败请检查上方错误信息。 exit /b 1逻辑说明%~dp0取批处理所在目录保证脚本可以放在任何位置。del /s /q清理旧产物避免.dcu污染。errorlevel 1判断上一步是否失败失败就跳转到:fail并返回非零退出码方便集成到 CI 里。参数说明如果你的 IDE 装在别的盘改IDE_PATH即可如果源码目录名不是Source改SRC变量。5.2 用 Git 管理修正版的差异修正版最大的价值是“可追溯”。我一般会把原始包和修正版分别放在两个分支original分支存官方原版fix-berlin分支存修正后的版本。每次 IDE 升级或控件包更新用git diff original fix-berlin看改了哪些单元引用和包配置。这样下次换到 Delphi 11 或 12 时只需要在fix-berlin基础上再开一个fix-alexandria分支把Winapi.DesignIntf换成新版本对应的单元名即可。5.3 一个验证修正版是否“干净”的小技巧装完修正版后新建一个空 VCL 项目只放一个RzButton然后编译成 Release 模式用tdump或Dependency Walker看生成的.exe依赖了哪些.bpl。如果除了rtl、vcl之外只依赖RaizeComponentsRun.bpl说明没有引入多余的包。如果发现依赖了RaizeComponentsDsgn.bpl说明设计期包被误链接进了运行时需要在项目选项里把设计期包从Runtime Packages里移除。注意Dependency Walker在新版 Windows 上可能报Error: At least one module has an unresolved import这是它自身的老问题不影响对.bpl依赖的判断。可以用tdump -em替代。5.4 我踩过的最深的一个坑早期我图省事直接把修正版的Lib目录整个拷到另一台机器上结果那台机器的 Berlin 版本号差了一个小版本.dcu格式不兼容编译时报F2063 Could not compile used unit RzCommon。血泪经验.dcu永远不要跨机器、跨 IDE 版本拷贝必须在本机重新编译。后来我养成了一个习惯——任何控件包的Lib目录都不进版本库只提交Source和dpk编译产物由脚本生成。这样虽然每次换机器要多花两分钟编译但省掉了无数“为什么昨天还好今天就不行”的后悔药。希望帮到你。本文还有配套的精品资源点击获取