简介这套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编译器版本号变成 24System.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*.pas控件源码编译 DPK 时依赖Source\Include\Raize.inc公共 include 头文件必须加入 Library 路径Packages\RaizeRuntime.dpk运行时核心包先编译并安装Packages\RaizeDesignComponents.dpk设计期控件包后编译并安装BPL\Win32*.bpl预编译 32 位包可跳过源码编译直接用DCU\Win32*.dcu预编译 32 位 DCU可并入 Library 路径InstallDoc\readme.txt版本记录与安装步骤先阅读最容易被忽略的是 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 BerlinHelp 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。卸载干净后重启 IDETool 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 或者 Cant 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 pathIDE 启动即加载。注意全局路径里不要包含 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 路径错配希望也能帮到你。本文还有配套的精品资源点击获取