简介：这套Raize 6.1.1.12组件包是针对Delphi 10.1 Berlin环境的修正发布版，主要面向使用Raize可视化控件的桌面应用开发者。原版安装后常因pas文件错误导致编译失败，作者已修正相关单元并调整配置文件，解压至C:\Program Files\Raize\后运行RC6\Source下的!Build_RC6.cmd即可完成安装部署。包内共956个文件，压缩后约10.74MB，涵盖hpp头文件、dcu编译单元、pas源文件、dpk包文件及bpl运行时库等，同时包含bmp图片资源与dfm窗体模块，可满足控件编译、界面设计与运行分发的完整需求。目前已有330人学习下载。通过此版本，开发者可省去手动排查Raize源码错误的麻烦，获得可直接编译通过的组件环境，适用于基于Delphi 10.1 Berlin进行快速界面开发的中高级程序员。

1. 为什么还要折腾 Raize：一个老组件库在 Berlin 下的现实价值

Raize 6.1.1.12 在 Delphi 10.1 Berlin 里依然有一批忠实用户，不是因为新项目非要选它，而是大量遗留系统里到处是 TZLabel、TZListBox、TZToolBar 这些控件。我最近接手一个十年份的内部工具，打开工程就是一堆 "File not found: Raize.inc"，再到 "Unresolved external"——半天时间耗在编译环境上。后来用上这个 cocashu 修正版，才明白问题不在业务代码，而是官方 Raize 包对 Berlin 编译器的兼容性早就跟不上了。这个修正版把源码里的条件编译分支补全，针对 Berlin 的 RTL 调整了类型引用，并附带打包好的编译脚本和 DCU，核心目的就是让你在 Berlin 下能顺利装上 Raize 6.1.1.12，继续跑老项目。本文就是一份从零开始的现场安装说明：怎么识别版本、怎么配路径、编译时能遇到哪些坑，以及验证是否装成功。适合正在维护老系统、被迫升级工具链、又不想重写界面的开发者。如果你是纯新项目，我反倒不建议入 Raize；但如果你被老代码绑着，照着这篇做能少走三个晚上的弯路。

2. 拿到修正版先看清楚：文件结构与版本识别

2.1 修正版与官方版的差异

Raize 6.1.1.12 官方版发布时对应的 Delphi 版本还比较早，源码里大量使用旧式条件编译宏。到了 Delphi 10.1 Berlin，编译器版本号变成 24，System.Types、System.UITypes 等单元的内部类型排列也变了。官方包里的{$IFDEF UNICODE}、{$IFDEF CLR}这类分支，在 Berlin 下很多命中不了新路径，导致编译到一半就报类型不一致。修正版的工作就是逐文件检查条件编译，补上{$IF CompilerVersion >= 24}这类分支，同时把 DPK 里的依赖顺序理顺。换句话说，你在 IDE 里打开修正版的设计期包，它会自动按依赖顺序先编译运行时包，而不像官方包那样要你手动一个个排顺序。

很多人拿到修正版以后，习惯性先找 setup.exe，实际上这个资源的核心是源码和编译脚本。包里虽然有预编译 DCU，我仍然建议从源码重新编译一遍。因为预编译 DCU 里记录的是别人机器上的绝对路径和编译选项，如果他的 IDE 版本和你差了一个小升级，加载时可能报 "Compiled with a different version of System.Types"。从源码编译虽然多花十几分钟，后面却省去一串玄学错误。

2.2 解压后该看哪些文件

修正版解压后，目录结构大致如此（以我手上这份资源为参照）：

最容易被忽略的是 Source\Include 目录里的 Raize.inc。它被几乎每个 pas 文件 include，编译器只有在你把该目录加入搜索路径时才能找到它。我见过不少人只加了 Source 根目录，没有加 Include 子目录，结果反复报 "File not found: Raize.inc"。另外，Packages 目录下有时会出现带版本后缀的包文件，比如 RaizeComponents_Berlin.dpk。那个才是针对 Berlin 的。如果你打开的是不带后缀的旧 DPK，编译时会有一大堆版本冲突报错。先读 readme.txt 再动手，能省一半时间。

2.3 确认你的 Delphi 版本与平台

打开 Delphi 10.1 Berlin，Help > About 里会显示内部版本号 24.0。注意不要和 10.0 Seattle 的 23.0 混淆。如果你实际是 10.2 Tokyo 或更高版本，修正版的条件编译分支未必覆盖，直接按本文操作很可能编译失败，但大原则相同。

平台方面，Windows 上的 Delphi 10.1 支持 Win32 和 Win64 两种编译目标，IDE 本体是 32 位进程，所有设计期 BPL 必须加载到 32 位 IDE 中。Raize 源码可以编译为两种平台，但修正包预编译 DCU 通常只给 Win32。如果工程需要 Win64，你必须从源码重新编译一次 Raize 包，并且在编译时把包的目标平台切到 Win64。这里有一个非常隐蔽的坑：在 IDE 中打开 DPK 时，项目管理器界面上的目标平台默认是 Win32，你要右键包名、选择 Project Options，把 Target Platform 改成 Win64 再编译。否则即使你完成了所有步骤，切到 64 位编译目标时依然提示找不到 DCU。

确认完版本和目标平台后，还要检查资源解压路径。不要放在带中文或空格的目录，比如 C:\用户\张三\下载\Raize_修正版。我在这里翻过车：编译器处理 DPK 相对路径遇中文目录直接中断，报错提示的文件路径看起来又是正常的，非常折磨。我后来一律解压到 D:\Libraries\Raize_6.1.1.12 这种纯英文路径，问题消失。

另外，在安装前最好检查一下 IDE 的 Registered Packages 列表里有没有旧的 Raize 残留。打开 Component > Install Packages，如果看到 "Raize Components 5.x" 之类的旧项，先选中并 Remove。否则新版 BPL 注册时会因为文件命名冲突提示 "Package ... contains a unit named ... which was already installed"。卸载干净后，重启 IDE，Tool Palette 里的旧 Raize 节点也会一起清掉。

3. 安装前的准备：环境变量、IDE 和权限

3.1 关闭 IDE 与杀毒软件

安装 Raize 的包，本质是把 BPL 加载到 bds.exe 进程，再在注册表登记包信息。如果 IDE 还开着，BPL 文件被锁定，复制或覆盖时会报 "Permission denied" 或 "File in use"。所以安装前先关掉所有 Delphi 实例，然后打开任务管理器，搜索 bds.exe、rcore.exe 进程，确认没有残留。如果还有后台进程，结束掉再继续。注意 dcc32.exe 如果有残留，说明还有工程在编译，等编译完再关闭，别强行结束。

杀毒软件和 Windows Defender 有时会把修正包里的补丁文件误报为风险工具，甚至在编译过程中隔离掉中间文件。这会导致一种很隐蔽的现象：第一次编译成功了，改一行代码再编译就报找不到常量，但查看了文件，文件明明在。解决办法不是关闭防护，而是把整个资源目录加入排除列表。我一般会在这里添加 D:\Libraries\Raize_6.1.1.12 和 IDE 的 BPL 输出目录，这样既不降低防护，也不会在构建链路上被拦腰截断。

3.2 设置好 Windows 用户权限

Raize 的包在 IDE 注册时，会写 HKEY_CURRENT_USER\Software\Embarcadero\BDS\24.0\Known IDE Packages，这个键普通用户有写权限。但同时它会尝试把 BPL 放到公共路径，比如 C:\Program Files (x86)\Embarcadero\Studio\18.0\bin，这个路径普通用户没有写权限。所以右键 Delphi IDE 图标，选择"以管理员身份运行"是最省事的做法。在管理员环境下安装的包，注册表信息对所有用户可见，之后普通用户启动 IDE 也能加载。

不过要注意，管理员环境下做的操作如果依赖环境变量，普通模式启动时可能读不到。比如你在管理员 IDE 里给系统环境变量添加了 Raize 路径，普通模式启动时 IDE 读到的是用户级环境变量，于是路径失效。我通常的做法是：管理员环境安装包，普通环境验证包。验证时如果 Tool Palette 里的 Raize 节点消失，多半是库路径写入位置不对，回到 4.2 重新配置路径。

3.3 备份你的 Delphi 环境

第三方组件包的安装最怕的就是把 IDE 配置搞乱。Raize 本身不卸载，但重复装不同版本时，旧的 BPL 和 DCU 残留在系统目录或注册表里，会直接影响后续编译。为了给安装上"后悔药"，先备份 Delphi 配置。Delphi 10.1 Berlin 的关键配置在注册表 24.0 键下。用管理员 PowerShell 执行：

# 备份用户级配置到文件 reg export "HKCU\Software\Embarcadero\BDS\24.0" "D:\backup_berlin.reg" /y # 备份系统级配置（如果存在） reg export "HKLM\Software\Embarcadero\BDS\24.0" "D:\backup_berlin_global.reg" /y

这两条命令会将用户与系统的 IDE 配置整体导出。如果导出后的 reg 文件只有几 KB，说明配置没有集中在那里，此时还可以备份 IDE 安装目录下的 .env 文件，它保存了库搜索路径等环境变量。常见路径是 C:\Program Files (x86)\Embarcadero\Studio\18.0\bin\env.24.0.dll，但实际文件后缀可能是 .desktop 或 .env。把该目录下包含 24.0 的 env 文件复制一份到 D:\backup\ 即可。

备份好注册表和 env 文件以后，安装过程中无论出了什么乱子，都能通过双击 reg 文件或替换 env 文件快速恢复。我还会顺手把当前正在调试的工程 .dproj 文件复制一份，防止 IDE 在测试时自动改写了项目搜索路径。有了这三重保障，再往前操作就大胆了。

4. 安装 Raize 6.1.1.12 的完整步骤：从包注册到 Tool Palette 显示

4.1 运行安装程序或手工注册

修正版资源如果没有引导安装 exe，那多半是源码包形态。源码包的安装流程是：在 IDE 中打开 DPK，依次编译并安装 Runtime 和 Design 两个包。先说编译顺序。打开 Resource 里的 Packages\RaizeRuntime.dpk，在 Project Manager 中右键该包，选择 Compile。编译期间会弹出一个对话框，提示是否要 Install 这个包。对于 Runtime 包，选 No。因为它不包含设计期组件，安装到 IDE 也不会在 Tool Palette 里增加任何节点，反而会让后续 Design 包的安装变得混乱。

Runtime 包编译成功后，接着打开 RaizeDesignComponents.dpk，同样右键 Compile。这次编译完成后提示 Install，选 Yes。此时 IDE 会立即加载设计期包，如果一切正常，Tool Palette 会出现 "Raize" 节点。如果加载失败，常见的报错是 "Cannot load package ... The module was compiled with a different version of System.Rtti"。这说明你编译 Design 包时，IDE 用的目标平台和 Runtime 包不一致，比如 Runtime 包编译成了 Win32，而 Design 包编译成了 Win64。解决方法是回到编译前，把两个包的目标平台都改成 Win32，或者都改成 Win64，保持同步。

4.2 给安装的 BPL 指定正确路径

编译完成后，BPL 文件默认可能输出到 IDE 的某些目录下，也可能是当前工程的输出目录。为了避免把 BPL 散落得到处都是，我会先把编译好的 BPL 和 DCP 文件统一复制到一个专用目录，比如 D:\Raize\BPL。然后打开 IDE 的 Tools > Options > Delphi Options > Library，在 Library Path 中添加以下路径：

D:\Libraries\Raize_6.1.1.12\Source D:\Libraries\Raize_6.1.1.12\Source\Include D:\Libraries\Raize_6.1.1.12\DCU\Win32 D:\Raize\BPL

注意路径顺序。Source 目录必须放在 DCU 之前，因为源码更新时编译器优先使用最新源码。Include 目录专门用来定位 Raize.inc。DCU 目录用于放置编译产生的 .dcu 文件，这里要考虑平台分离。修正版提供的 DCU\Win32 是给 32 位编译用的；如果你要支持 64 位，先不要在 Library Path 里写死 DCU\Win64，而是等到需要时再重新编译源码生成对应的 DCU，自动输出到相应文件夹。

这里有个容易忽略的参数：在 Library Path 的右侧有一个 "Default" 按钮，点它可以恢复默认值。千万别为了省事直接把整个 Library Path 替换掉，那样会丢失 Delphi 自带的系统单元路径。应该把 Raize 的路径追加到列表最后面，或者至少不要排在 System.SysUtils 等系统路径之前。否则后续编译工程时，IDE 可能优先找到 Raize 带的某个同名单元，导致奇怪的类型冲突。

4.3 在 IDE 中安装组件包

路径配置好后，回到 Component > Install Packages。点击 Add，选择之前编译好的 RaizeDesignComponents.bpl。文件路径要和你 Library Path 中填写的 BPL 目录一致。选中后，IDE 左下角会显示包注册进度，加载完成会弹出提示 "Package C:...\RaizeDesignComponents.bpl was installed successfully"。

如果你加载时看到错误对话框，里面提到某个 BPL 找不到，那就说明这个设计期包还依赖其他运行时 BPL。不要慌，看看错误内容里缺少的是哪个文件名。Raize 的控件包通常只依赖 RaizeRuntime.bpl，如果提示缺少那个，把 RaizeRuntime.bpl 也放到同一个 BPL 目录里，再重新 Add 一次。如果提示缺少其他第三方包，那说明你在配置文件里写的运行时依赖路径不全，回到 4.2 把相关路径都加进去。

Install Packages 列表中的包，最好勾选右下角的 "Load on startup" 选项。这个选项决定了 IDE 启动时是否自动加载 Raize 包。如果不勾，重启 IDE 后 Raize 节点会消失，你还需要手动再 Add 一次，非常折腾。勾选后，包信息会写入注册表，下一次打开 IDE 自动加载。

4.4 验证安装

安装完成后，新建一个 VCL Application，从 Tool Palette 展开 "Raize" 节点，拖一个 TZLabel 到窗体上。如果设计期能正常显示文本，说明控件包已经工作了。再拖一个 TZListBox，切换到代码视图，在 FormCreate 里写下面这段最小验证代码：

procedure TForm1.FormCreate(Sender: TObject); begin ZListBox1.Items.Add('Raize install check'); ZListBox1.Items.Add('Berlin 10.1'); ZListBox1.Items.Add('OK'); end;

这里使用了 TZListBox 的 Items 属性和 Add 方法。这段代码虽然简单，但能同时验证设计期包和运行期包是否都正常。如果编译时报 "File not found: Raize.inc" 或 "Unit not found: RaizeUnit"，那就是 Library Path 漏了 Include 目录，回去补。如果编译通过但运行起来 TZListBox 是空白，说明设计期包安装成功，但运行时包没有正确加载，检查 Install Packages 列表里有没有 RaizeRuntime.bpl 被错误地安装成设计期包。正常情况下 Runtime 包不需要安装，它只作为依赖项被自动加载。

验证结束后，记得关闭 IDE，重新以普通用户启动一次，确认 Raize 节点仍在。这是检验注册表权限和路径配置是否成客户的最后一步。

5. 避坑：安装和编译中的常见问题

5.1 一直提示 "File not found: Raize.inc" 怎么解？

现象：编译 DPK 或工程时，编译器反复报File not found: Raize.inc，即使你已经把 Source 目录加入 Library Path。

原因：Raize.inc 位于 Source\Include 子目录，不在 Source 根目录。编译器搜索的是 Library Path 里列出的具体目录，不会递归查找子目录。很多人只加了D:\Libraries\Raize_6.1.1.12\Source，没加Source\Include，于是 head 文件找不到被 include 的目标。

解决：在 Tools > Options > Delphi Options > Library 中将 Include 目录显式加入 Library Path。注意顺序，Include 目录要排在 Source 之前还是之后？一般放在之后即可，因为 Source 里可能还有别的同名 inc 文件。我习惯把两个都写全，并且把 Include 放在 Source 后面，这样 include 的优先级明确。改完路径后，重启 IDE 再编译，问题消失。

5.2 编译报错找不到某个 DCU

现象：你的工程在 Win32 目标下编译正常，切到 Win64 后报 "Unit RaizeXXX was compiled with a different version of System.Types" 或者 "Can't locate unit RaizeXX.dcu"。

原因：预编译 DCU 只有 32 位版本，64 位编译器需要独立的 DCU 集合。你没有在 64 位目标下重新编译 Raize 包，导致编译器在默认输出目录里找不到匹配的 64 位 DCU。

解决：不要手动复制 32 位 DCU 到 Win64 目录。正确做法是重新编译 Raize 的 Runtime 和 Design 包。在 IDE 的项目管理器中打开包文件，右键目标平台，选择 Win64，然后 Compile。编译产物会自动生成到 DCU\Win64 目录。如果你的 Library Path 中已经预填了DCU\Win32，千万别把它改成DCU\Win64——这样会把 32 位工程的 DCU 路径也指向 64 位，导致 Win32 编译反而出错。最稳妥的方法是分别给 Win32 和 Win64 两个目标各加一个搜寻路径，让 IDE 自动按当前目标匹配。

5.3 窗体设计器里控件不显示

现象：包安装成功，Tool Palette 里有 Raize 节点，拖一个 TZToolBar 到窗体上，设计器里只显示一个空白矩形，运行后控件又是正常的。

原因：Raize 的某些控件在设计期有单独的绘制逻辑，需要在设计期包中注册资源。如果你的 Install Packages 列表里只有 RaizeRuntime.bpl，没有 RaizeDesignComponents.bpl，那么设计期绘制函数缺失，IDE 会按默认控件框架显示空白。

解决：打开 Component > Install Packages，确认列表中确实包含 RaizeDesignComponents.bpl。如果有但依然空白，检查这个设计期包的目标平台是否和 IDE 一致（均为 32 位）。如果之前误用 64 位编译过，重新编译成 Win32 再安装。装完后重启 IDE，拖一个 TZToolBar 再测试，设计器应该能预览到完整外形。如果重启后仍然空白，可能是因为 IDE 的设计期着色组件缓存了 GDI 资源，这时尝试关闭所有窗口，重新打开工程，而不是重启整个 IDE。

5.4 和第三方皮肤控件冲突

现象：在使用了 VCL Styles 或第三方皮肤控件的工程里，Raize 的下拉列表框、组合框弹出层出现白色背景，点击后列表瞬时就收起，甚至造成 IDE 设计器卡死。

原因：Raize 控件有自绘机制，会拦截 WM_PAINT 绘制自定义边框和背景。皮肤控件在全局范围内 hook 了系统颜色和绘制样式，碰上 Raize 这类高度自绘的组件，消息冲突在所难免。尤其 TZComboBox 的弹窗列表是独立窗体，皮肤控件无法正确刷新它的背景画刷。

解决：如果使用 VCL Styles，可以让 Raize 控件不参与样式重绘。在窗体的 OnCreate 里，把关键控件的 StyleElements 调整为不包含 seClient 和 seBorder。因为 StyleElements 是公开属性，直接写：

ZComboBox1.StyleElements := []; ZNavBar1.StyleElements := [];

如果是第三方皮肤程序，更稳妥的做法是在皮肤设置中把 Raize 控件所在的窗体排除出皮肤渲染范围，或者把 Raize 的窗口类名加入皮肤控件的排除列表。在列表里填入 "TZListBox"、"TZComboBox"、"TZToolBar" 等类名，让皮肤控件跳过对这些窗口的样式处理。这类排除配置通常出现在皮肤控件的全局设置对话框中。改完以后，Raize 控件使用 Windows 原生样式绘制，皮肤不再干扰，同时你的软件整体皮肤效果依然保持在不冲突的控件上。

这种多控件库共存的问题没有通用公式，但记住一个大前提：自绘组件和皮肤组件最好不要同时作用在同一窗口。要么让皮肤排除 Raize，要么在 Raize 里禁用样式重绘，别两边都抢。

6. 让 Raize 在新工程里用得更顺手：项目配置与安装后验证

Raize 装好以后，我建议做一次全局配置，而不是把它当成一次性工程。打开 Tools > Options > Delphi Options > Library，把 Raize 的 Source、Include、DCU 三个路径填进默认的 Library Path。这样以后每个新工程不用手动加 search path，IDE 启动即加载。注意，全局路径里不要包含 BPL 目录，因为 BPL 是在 Installed Packages 里按包登记的，不需要也不应该出现在 Library Path 中。

配置完成后，写一个小例子做最终验证。我习惯放一个 TZNavBar 在窗体左侧，配合 TZLabel 显示状态。TZNavBar 是 Raize 里比较有辨识度的控件，用它来验证安装是否彻底很合适。下面这段代码演示了在运行时向 TZNavBar 添加一个分组和项目：

procedure TForm1.FormCreate(Sender: TObject); var Group: TZNavBarGroup; Item: TZNavBarItem; begin Group := ZNavBar1.Groups.Add('System'); Item := Group.Items.Add('CPU Usage'); Item.OnClick := NavBarItemClick; end; procedure TForm1.NavBarItemClick(Sender: TObject); begin Caption := 'Raize nav item clicked'; end;

这段代码涉及 TZNavBar 的分组和项目对象，编译通过说明控件的类型定义完整。运行后点击项目，标题栏文字变化，说明事件绑定链路也正常。如果这段代码能跑通，Raize 6.1.1.12 在你的 Berlin 环境里基本没有隐患了。

完成这些验证后，还有一个容易被遗忘的收尾步骤：清理临时 DCU。编译工程时 IDE 会在工程目录下生成 .dcu 和 .dcp 文件，它们可能混入了之前测试时不同平台的产物。把工程目录下的 __history、.dcu 目录删掉，重新编译一次，确保最终可执行文件是从干净状态构建的。这一步能排除很多"刚才还能跑，现在又编译不过"的临时缓存问题。

从那以后，我每次在 Berlin 里装完 Raize 一类的组件包，都会强制自己走一遍"重启 IDE → 新建空白 VCL → 放置 Raize 控件 → 写一段小事件处理"的四步验证流程，缺一步都不算安装完成。这套流程帮我排除过至少两起奇怪的渲染问题和一例 64 位 DCU 路径错配，希望也能帮到你。

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