企业官网建设流程全解析

简介：Raize_6.1.1.12_DX10_1_Berlin_cocashu修正版面向使用Delphi/C++Builder Berlin（10.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 Tokyo（Berlin）时期的老项目，大概率会在某个时刻撞上 Raize Components 这个控件包。标题里的Raize_6.1.1.12_DX10_1_Berlin_cocashu修正版，拆开看就是四层信息：控件包版本 6.1.1.12、目标 IDE 是 DX10.1（Delphi 10.2 Tokyo，代号 Berlin）、带 DX10 编译支持、以及一份社区流传的“修正版”。它解决的核心问题很具体——原版安装包在新版 IDE 下编译报错、设计期包加载失败、部分控件在 VCL 高 DPI 下渲染异常。适合谁？正在维护 Berlin 及以上版本 Delphi 项目、又不想推倒重来换控件的团队。这一章先把“它是什么、为什么会有修正版”讲清楚，后面几章再落到安装、编译、排错和参数调优。

2. 修正版到底修了什么：从包结构到编译链的拆解

2.1 原版在 Berlin 上翻车的三个典型位置

Raize Components 6.1.1.12 发布时，官方主要覆盖到 Delphi 10.1 及更早版本。到了 Berlin，IDE 的包编译规则、单元作用域、以及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。如果顺序反了，设计期包会因为找不到运行时包的符号而报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', encoding='utf-8', errors='ignore') 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', encoding='utf-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(r'D:\Components\Raize\Source')

逻辑说明：REPLACE_MAP里的正则用了\b单词边界，避免把MyDesignIntfHelper这种自定义单元误伤。errors='ignore'是为了兼容老文件里可能存在的非 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+ ^ -I"D:\Components\Raize\Source" ^ -N"D:\Components\Raize\Lib" ^ -E"D:\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+ ^ -I"D:\Components\Raize\Source" ^ -N"D:\Components\Raize\Lib" ^ -E"D:\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_PATH=C:\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 2>&1 del /s /q "%LIB%\*.dcu" >nul 2>&1 del /s /q "%LIB%\*.bpl" >nul 2>&1 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，编译产物由脚本生成。这样虽然每次换机器要多花两分钟编译，但省掉了无数“为什么昨天还好今天就不行”的后悔药。

希望帮到你。

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