简介：Raize 6.1.1.12 DX10.1 Berlin 修正版面向使用 C++Builder 10.1 Berlin 的 Delphi/C++ 开发者，针对原版组件包中 pas 文件报错导致编译失败的问题做了修复，并已调整好配置文件，解压至 C:\Program Files\Raize\ 后执行 RC6\Source 下的 !Build_RC6.cmd 即可完成安装，适合需要稳定使用 Raize 控件库的中高级开发者。压缩包共 956 个文件，约 10.74MB，以 hpp、dcu、pas、dfm 等源码与编译单元为主，另含 bmp、res、ico 等界面资源，以及 dpk、dproj、groupproj 等工程与包文件，并附带安装说明文档，目录结构完整、便于按模块查阅。目前已有 329 人学习下载。读者可直接获得一套可编译通过的组件源码与预置配置，省去手动排查 pas 错误、逐项调整路径的时间，同时可参考其工程组织方式，用于自身控件包的编译与部署实践。
1. Raize 6.1.1.12 DX10.1 在 Berlin 环境下的安装路径与版本选择
Raize 6.1.1.12 DX10.1 这套组件包，在 Delphi Berlin 时代的项目里出现的频率相当高。它本质上是一组 VCL 控件库，覆盖了从按钮、表格到布局容器的常用 UI 元素，很多老项目在迁移到 Berlin 之后，第一件事就是把 Raize 重新装一遍。但版本对不上、编译顺序错一步，IDE 就会在启动时直接报包加载失败，连设计器都打不开。我见过最典型的情况是：装完之后新建一个 VCL 窗体，拖一个 Raize 控件上去，IDE 立刻弹出一串“Class not registered”的提示，然后整个窗体设计器变成灰白一片。这不是控件本身有问题，而是包编译顺序和运行时包路径没配对。这套环境适合两类人：一是维护 Berlin 老项目的开发者，二是需要在 DX10.1 运行时环境下做界面兼容的团队。如果你正在用 Berlin 做 VCL 开发，并且项目里已经引用了 Raize 的单元，那这篇安装记录可以直接照着走。
2. 安装前的环境核对：Berlin 版本、DX10.1 运行时与包依赖
2.1 确认 Berlin 的编译器和运行时版本
Raize 6.1.1.12 这个版本号对应的是 Delphi 10.1 Berlin 的编译器，不是 10.2 也不是 10.3。很多人拿到包之后直接往 Tokyo 或 Rio 里装，结果第一步编译就报“Unit not found”，因为 Berlin 的 RTL 单元命名和后续版本有差异。我一般会先打开 IDE，在 Help → About 里确认版本号是 10.1 Berlin，并且 Update 补丁至少打到 Update 2。DX10.1 指的是 DirectX 10.1 相关的运行时依赖，Raize 里有一部分控件用到了图形渲染接口，如果系统里的 DirectX 运行时版本低于 10.1，设计器预览会直接黑屏。检查方法很简单，在命令行里跑一下：
dxdiag /t %TEMP%\dxdiag_out.txt然后打开生成的文本，找“DDI Version”这一行，确认是 10.1 或更高。这个步骤看起来多余，但我确实遇到过因为 DirectX 运行时被其他软件降级导致 Raize 控件在设计器里渲染异常的情况。另外，Berlin 的默认编译输出路径是C:\Users\Public\Documents\Embarcadero\Studio\18.0\Dcp，这个路径后面配置包输出的时候要用到，先记下来。
2.2 检查已安装的包和冲突组件
在装 Raize 之前，必须确认 IDE 里没有残留旧版本的 Raize 包。打开 Component → Install Packages，在列表里搜“Raize”，如果看到任何条目，先全部 Remove，然后手动去C:\Users\Public\Documents\Embarcadero\Studio\18.0\Bpl目录下把对应的.bpl文件删掉。这一步不做的话，新包编译出来之后会和旧包抢注册同一个控件类，结果就是 IDE 启动时弹“Duplicate entry”错误，严重的时候直接崩溃。我自己的习惯是：在装任何第三方控件包之前，先把Bpl和Dcp两个目录整个备份一份，出问题了直接还原，比一个个卸载快得多。另外，如果你的项目里用了其他 UI 库，比如 DevExpress 或者 TMS，要注意它们的包加载顺序。Raize 的包最好放在这些库之后加载，否则设计器里可能会出现控件面板图标错乱的情况。
2.3 准备编译所需的搜索路径和库路径
Raize 的源码包解压之后，目录结构一般是Source、Lib、Bin几个文件夹。在编译之前，需要在 IDE 的 Tools → Options → Environment Options → Delphi Options → Library 里，把Source目录加到“Library path”里。注意是加在“Library path”而不是“Browsing path”，因为编译的时候需要找到.pas文件。DX10.1 相关的头文件一般在Lib\DX10子目录下，这个路径也要一并加进去。我一般会单独建一个环境变量，比如RAIZE_ROOT，指向解压后的根目录，然后在 Library path 里用$(RAIZE_ROOT)\Source这种形式引用。这样做的好处是以后换版本只需要改环境变量，不用一个个改 IDE 配置。路径加完之后，点“OK”保存，然后重启 IDE，让路径生效。
3. 编译与安装 Raize 包：从源码到 IDE 注册的完整步骤
3.1 打开包组项目并设置编译目标
Raize 的包组文件通常是RaizePackages.groupproj，在Packages目录下。双击打开之后，IDE 的 Project Manager 里会列出多个包，比如RaizeComponentsRun.dpk、RaizeComponentsDesign.dpk等等。这里有一个关键点：先编译运行时包（Run），再编译设计时包（Design）。顺序反了的话，设计时包会因为找不到运行时包的接口而编译失败。我一般会右键点击包组，选择“Build All”，但在这之前，先确认 Project Manager 里每个包的“Target Platforms”只勾选了“Win32”。Berlin 时代 Raize 对 Win64 的支持并不完整，如果勾了 Win64，编译到一半会报一堆指针类型不兼容的错误。确认之后，右键RaizeComponentsRun.dpk，选择“Build”，等它编译完，再对RaizeComponentsDesign.dpk做同样的操作。
# 如果你习惯用命令行编译，可以用 dcc32 直接编运行时包 dcc32 -B -Q -W -$D- -$L- -$Y- -E"C:\Users\Public\Documents\Embarcadero\Studio\18.0\Dcp" RaizeComponentsRun.dpk这个命令里的-B表示重新编译所有单元，-E指定输出路径。注意-Q是安静模式，-W是显示警告。我一般会加上-$D-和-$L-来关闭调试信息和局部符号，这样编译出来的包体积小一点。命令行编译的好处是速度快，而且不会因为 IDE 的缓存问题导致奇怪的链接错误。但如果你对 dcc32 的参数不熟，直接用 IDE 的 Build 功能更稳妥。
3.2 安装设计时包并验证控件面板
运行时包编译成功之后，接下来要安装设计时包。在 Project Manager 里右键RaizeComponentsDesign.dpk，选择“Install”。IDE 会弹一个对话框，提示即将安装包并注册控件。点“Yes”之后，如果一切正常，你会看到控件面板里多出一个“Raize”标签页，里面排列着各种控件图标。这时候不要急着关 IDE，先新建一个 VCL Application，在窗体上拖一个TRzButton和一个TRzPageControl，看看能不能正常显示。如果控件拖上去之后变成空白或者报“Error creating control”，大概率是运行时包的路径没配好。回到 Tools → Options → Environment Options → Delphi Options → Library，确认“Library path”里包含了Dcp目录和 Raize 的Source目录。还有一个容易忽略的点：Berlin 的 IDE 在安装包之后，有时候不会自动刷新控件面板，需要手动关掉 IDE 再重新打开，控件才会出现。
3.3 配置 DX10.1 渲染相关的初始化参数
Raize 里有一部分控件，比如TRzGlassButton和TRzImageList，在 DX10.1 模式下需要额外的初始化参数。这些参数不是写在代码里的，而是通过一个配置文件RaizeDX.ini来控制的。这个文件一般在Bin目录下，内容大概是这样的：
[DX10] Enabled=1 Antialias=2 TextureQuality=1 MaxCacheSize=64Enabled=1表示启用 DX10.1 渲染路径，Antialias=2是 4x 抗锯齿，TextureQuality=1是中等纹理质量。MaxCacheSize控制纹理缓存的大小，单位是 MB。我一般会把MaxCacheSize调到 128，因为默认的 64 在复杂界面上容易频繁触发缓存回收，导致界面闪烁。这个文件改完之后，需要把它放到和可执行文件同一个目录下，或者放到系统 PATH 能访问到的路径里。如果你不确定放哪里，最保险的做法是放在项目输出目录下，然后在代码里用ExtractFilePath(ParamStr(0))拼出完整路径去加载。
4. 避坑与排查：Raize 安装过程中最常见的五个翻车点
4.1 现象：IDE 启动时报“Package RaizeComponentsRun.bpl can't be loaded”
原因通常是运行时包的输出路径和 IDE 的搜索路径不一致。Berlin 默认会在Bpl目录下找.bpl文件，但如果你编译的时候改了输出路径，或者用了命令行编译但没指定-E参数，包就会生成到当前目录下。解决方法是：打开 Component → Install Packages，找到 Raize 的条目，点“Edit”，把路径重新指向正确的.bpl文件。如果条目已经变成灰色不可编辑，先 Remove 再重新 Add。我自己的习惯是编译之前就在 IDE 里把每个包的 Output Directory 显式设成C:\Users\Public\Documents\Embarcadero\Studio\18.0\Bpl，这样就不会出现路径漂移。
4.2 现象：设计器里拖放 Raize 控件时 IDE 直接崩溃
这个问题的根源多半是 DX10.1 运行时和 Raize 的渲染线程冲突。Berlin 的 IDE 本身是 32 位进程，而 DX10.1 的某些接口在 32 位下需要额外的兼容层。解决办法是在RaizeDX.ini里把Enabled改成 0，先禁用 DX10.1 渲染，等设计完成之后再在代码里动态启用。具体做法是在窗体创建的时候调用RzDXInitialize，在窗体销毁的时候调用RzDXFinalize。这样设计器走的是 GDI 路径，不会崩溃，运行时走 DX10.1 路径，效果不受影响。这个坑我踩过两次，后来就养成了习惯：只要 IDE 一崩，先去改 ini 文件。
4.3 现象：编译时报“Unit RzCommon was compiled with a different version of Windows”
这是典型的单元版本冲突。原因是你项目里引用的Windows.pas和 Raize 编译时用的Windows.pas不是同一个版本。Berlin 的 RTL 源码在Source\Rtl\Win目录下，而 Raize 的包在编译时会优先搜索 Library path 里的路径。如果你在 Library path 里把 Raize 的Source目录放在了 RTL 目录前面，就会导致 Raize 用到旧的Windows.pas。解决办法是调整 Library path 的顺序，把$(BDS)\Source\Rtl\Win放在 Raize 的Source目录之前。或者更彻底一点，在 Raize 的包项目里，把“Use debug .dcus”关掉，强制重新编译所有依赖单元。
4.4 现象：控件面板里 Raize 标签页是空的
这种情况通常发生在你安装了设计时包，但没有安装对应的运行时包。Berlin 的 IDE 在加载设计时包的时候，会去检查它依赖的运行时包是否已经注册。如果运行时包没装，设计时包虽然能加载，但控件注册会失败，面板上就是空的。解决方法是回到 Component → Install Packages，确认RaizeComponentsRun和RaizeComponentsDesign两个条目都在列表里，并且都处于勾选状态。如果只有 Design 没有 Run，先 Add Run 包，再重新 Install Design 包。另外，如果你用的是 Berlin 的 Starter 版本，它不支持第三方包安装，这个限制没法绕过。
4.5 现象：程序发布到客户机器上报“Class not registered”
这是运行时包没有随程序一起发布导致的。Raize 的控件在 EXE 里只保留了接口引用，实际的类实现都在.bpl文件里。如果你编译的时候用了“Runtime Packages”，就必须把RaizeComponentsRun.bpl和rtl180.bpl一起拷到客户机器上，并且确保它们在系统 PATH 或者 EXE 同目录下。我一般会在项目里建一个Deploy文件夹，把需要的.bpl和.dll都放进去，然后用 Inno Setup 打包的时候一并带上。如果你不想带一堆.bpl，可以在项目选项里把“Build with runtime packages”取消勾选，这样所有代码都编进 EXE，但 EXE 体积会大很多，启动也慢一点。两种方式各有取舍，看你的发布场景。
5. 装完怎么验证：三个必做的检查和一个长期习惯
5.1 用最小工程做一次完整编译和运行
装完 Raize 之后，不要直接打开老项目去编译，那样出了问题你分不清是 Raize 的问题还是项目本身的问题。我一般会新建一个最简的 VCL Application，只放一个TRzButton和一个TRzEdit，然后编译成 Release 版本，跑到虚拟机里试一下。虚拟机的系统版本最好和客户环境一致，比如 Windows 7 SP1 或者 Windows 10 1809。运行起来之后，点一下按钮，在编辑框里输入几个字符，确认没有延迟、没有闪烁、没有报错。这个最小工程的作用是建立一个基线：如果它跑通了，说明 Raize 本身没问题，后面老项目出问题就是项目配置的事。
5.2 检查包加载日志和事件查看器
Berlin 的 IDE 在启动时会写一份包加载日志，位置在%APPDATA%\Embarcadero\BDS\18.0\CatalogRepository下面，文件名类似PackageCache.log。这个日志里会记录每个包的加载时间、路径和状态。如果 Raize 的包加载失败，这里会有详细的错误码。另外，Windows 的事件查看器里，应用程序日志下也会记录 IDE 崩溃时的模块信息。我遇到过一次 Raize 包加载失败，事件查看器里显示Faulting module name: RaizeComponentsRun.bpl，错误码是0xc0000005，查下来是 DX10.1 的 DLL 版本不对。后来把 DirectX 运行时重新装了一遍就好了。所以装完之后，花两分钟看一下这两个日志，能省掉后面很多排查时间。
5.3 验证 DX10.1 渲染路径是否真正生效
很多人以为在RaizeDX.ini里写了Enabled=1就完事了，其实不一定。DX10.1 的初始化需要硬件支持，如果你的显卡驱动太旧，或者虚拟机里没有启用 3D 加速，Raize 会自动回退到 GDI 模式，但不会报错。验证方法是：在程序里调用RzDXIsEnabled函数，如果返回True，说明 DX10.1 路径生效了；返回False就是回退了。我一般会在主窗体的OnCreate里加一行日志，把RzDXIsEnabled的返回值写到文件里，发布之前看一眼。如果客户机器上返回False，要么升级显卡驱动，要么就在代码里显式禁用 DX10.1，避免界面渲染出问题。
procedure TMainForm.FormCreate(Sender: TObject); begin // 检查 DX10.1 渲染是否启用，写入日志便于排查 if RzDXIsEnabled then OutputDebugString('Raize DX10.1 rendering: ENABLED') else OutputDebugString('Raize DX10.1 rendering: DISABLED (fallback to GDI)'); end;这段代码在 Debug 模式下会把信息输出到 IDE 的 Event Log 里，Release 模式下可以用OutputDebugString配合 DebugView 工具查看。注意RzDXIsEnabled是 Raize 提供的函数，不需要额外引用单元，只要包装好了就能直接调用。
5.4 我自己的长期习惯：装完必做一次“冷启动”测试
从那以后我每次装完 Raize 或者任何第三方控件包，都会强制走一遍“冷启动”流程：先把 IDE 完全关掉，等十秒钟，再重新打开，然后新建工程、拖控件、编译、运行。这个流程看起来简单，但能发现很多热启动状态下被缓存掩盖的问题。比如有一次我装完包之后直接编译，一切正常，但第二天早上来打开 IDE，发现 Raize 标签页不见了，原因是包注册信息没有持久化到注册表里。冷启动测试就是模拟第二天早上的状态，确保包是真的装好了，而不是靠 IDE 的临时缓存撑着。这个习惯帮我省掉了至少三次在客户现场才发现控件加载失败的尴尬。希望帮到你。
本文还有配套的精品资源，点击获取
