企业官网建设流程全解析

简介：Raize 6.1.1.12 DX10.1 Berlin 修正版面向使用 Delphi/C++Builder Berlin 的组件开发者，重点解决原包中 pas 文件错误引发的编译失败问题，适合需要稳定组件库并希望减少环境适配与报错排查时间的读者。压缩包共 956 个文件、约 10.74MB，内含 114 个 pas 源码、202 个 hpp 头文件、198 个 dcu 编译单元，以及 dfm 窗体、res 资源、dproj 工程和 dpk/bpl 包文件等，覆盖源码、设计期资源、工程配置与编译产物的完整层次。资源附带安装说明，配置文件已预先调整，并保留 RC6 源码目录下的构建脚本，便于对照包结构、核对编译依赖、复现构建过程和定位不同开发环境下的差异。对于需要检查包依赖关系、确认设计期资源是否齐全或复现原版组件包目录组织的开发者，这些文件具有较直接的参考价值。已有 330 人学习，适合中高级 Delphi 开发者用于组件安装、版本验证与排错参考。

1. Raize 6.1.1.12 在 Berlin 上是块什么料：先弄清楚再动手

标题里的三段信息得拆开看：Raize Components 6.1.1.12 是版本号，DX10_1 指的是 Delphi 10.1 Berlin 这套 IDE，cocashu 修正版一般意味着有人把原始发布包里的 .dpk/.dproj 工程文件、条件编译宏、单元搜索路径重新对了一遍，让它能在 Berlin 的编译器下直接打开、直接编译。这类修正通常不动控件本身的源码逻辑，修的是“工程配置”这层外壳。它解决的问题很具体：官方老包在新 IDE 里一打开就报找不到单元、设计期包装不上、组件面板空白。适合还在维护 VCL 桌面项目、需要在 Berlin 上补齐 Rz 系列控件的人；如果你的项目早就迁到 FMX 或者更高版本 IDE，这套东西对你的价值有限。

2. 解开压缩包先别双击：目录、包与搜索路径的对齐

拿到一个第三方 VCL 组件包，最忌讳的操作是解压完直接找 .dpk 双击。那个动作会把 IDE 的默认编译输出目录、默认配置、默认平台全部套上去，等你发现 DCU 到处乱飞的时候，清理成本比重新装一遍还高。正确顺序是：先看清目录结构，再决定哪几个包要装，最后把“源码路径 / DCU 输出路径 / BPL 输出路径”三条线一次性配对，后面八成的问题都是这三条线错位引起的。

2.1 先认清 Packages 目录里那几个 .dpk 的分工

Raize 这类库的包目录通常是成对出现的：一个运行期包，一个设计期包。运行期包里只 contains 业务单元，编译产物是 .bpl + 一堆 .dcu，你的应用程序运行时依赖它；设计期包里 contains 的是注册单元，作用是往 IDE 的组件面板里注册图标和属性编辑器，它本身不被应用程序引用，但它在安装时必须能找到运行期包。

判断方法很土但有效：用文本编辑器打开 .dpk，看requires段里有没有引用另一个包名。如果 A 包 requires B 包，那 A 基本就是设计期包，B 是运行期包。修正版里最容易出问题的地方就在这一句requires——原作者可能写的是老版本 IDE 的包名（比如带版本后缀的rtl、vcl引用），Berlin 下这些名字对不上就会直接编译失败。

提示：动手前把整个目录复制一份出来做“工作副本”，原始压缩包留档。修正版的路径引用经常是相对路径，你一旦在原始目录里编译，DCU 会散落到 Source 目录里，回头分不清哪份是干净的。

2.2 Library Path 与 DCU 输出目录：一次配对，后面少受罪

三条路径的规划原则是“源码只读、产物集中、按平台分目录”。源码目录永远不要往里写东西；DCU 输出统一到一个按平台分的目录（win32 / win64）；BPL 输出统一到一个目录，并且这个目录要能被 IDE 找到。我在自己的机器上是这么摆的：

D:\Components\Raize\6.1.1.12\ ├─ Source\ 源码，只读 ├─ Packages\ .dpk / .dproj ├─ Demos\ ├─ build\ │ ├─ dcu\win32\ 运行期包的 DCU 输出 │ ├─ dcu\win64\ │ ├─ bpl\win32\ 运行期包 BPL 输出 │ └─ bpl\win64\

对应到 IDE 里的两处设置（Tools > Options > Environment Options > Delphi Options > Library）：

• Library path 追加D:\Components\Raize\6.1.1.12\Source，这样你自己的项目 uses 了 Rz 单元时能直接找到源码；
• 同一页的“Package output directory”和“DCP output directory”不要指向系统目录，指向你项目自己的 build 目录，避免不同版本的包互相覆盖。

这一步看着琐碎，但它决定了后面第 4 章里一大半报错会不会出现。血泪经验是：同一个 IDE 里装过两个以上第三方控件库的人，几乎都被“BPL 被同名文件覆盖”坑过一次，症状是 IDE 启动报找不到某个包，但你明明刚装完。

2.3 用 dcc32 做一次编译体检，别把问题带进 IDE

在打开 IDE 之前，先用命令行把运行期包编译一遍，是成本最低的排错手段。IDE 的编译输出窗口会被 hint 和 warning 刷屏，命令行的 -Q 参数能把这些噪音压掉，只留 error，一眼就能看出修正版的工程文件到底还差什么。

cd /d D:\Components\Raize\6.1.1.12\Packages dcc32 -B -Q ^ -DVER310 ^ -U"..\Source" ^ -I"..\Source" ^ -N0"..\build\dcu\win32" ^ -E"..\build\bpl\win32" ^ RaizeComponentsVcl.dpk

参数逐个解释，这几个后面改配置时天天要用：

• -B：全量重建，忽略已有 DCU。第一次编译和改过条件宏之后必须带，否则编译器会拿旧的 .dcu 糊弄你。
• -Q：安静模式，只输出错误。想看到完整信息就去掉它。
• -DVER310：定义一个条件编译符号。Delphi 10.1 Berlin 的编译器版本号是 31，标准宏是VER310，编译器本身会自动定义，这里显式写一遍是为了防止某些 .dpk 里用{$DEFINE}覆盖掉了默认定义。
• -U：单元搜索路径，指向 Source。修正版里 .dpk 的 contains 语句如果是相对路径且层级写错，这一行能兜底。
• -I：include 文件搜索路径。老源码喜欢用.inc集中放条件定义，缺了这条就报F1026 File not found。
• -N0：DCU 输出目录，注意是数字零不是字母 O，这是 Delphi 命令行里最容易写错的一个参数。
• -E：BPL / EXE 输出目录。

编译通过的标准不是“没有 error”就完事，而是去build\dcu\win32里数一下 .dcu 的数量，和你预期的单元数对得上。如果数量明显偏少，说明 .dpk 的 contains 段被人删过，或者部分单元因为条件编译被整段跳过了——这种“编过了但少东西”的情况，到设计期安装时才会爆出来，更难受。

3. 编译与安装：把运行期包和设计期包分两步走

很多人在这里栽跟头，是因为把“编译”和“安装”当成一件事。对 Delphi 的包机制来说，这是两个完全不同的动作：编译运行期包产出 BPL 和 DCU，是文件系统层面的事；安装设计期包是往 IDE 的组件面板和注册表里写东西，是 IDE 层面的事。顺序错了，症状就是“面板上有图标，一拖到窗体上就报错”，或者“包明明装了，重启 IDE 就没了”。

3.1 运行期包：先编译成 BPL，放到位再谈其它

承接上面的命令行，运行期包编译成功后，你要确认的是 BPL 真的生成在你指定的目录，而不是 IDE 的默认输出目录。修正版最常见的一个残留问题就是 .dproj 里写着<DCC_BplOutput>指向某个老机器的绝对路径，比如C:\Users\xxx\Documents\...，你在自己机器上编译，文件就生成失败或者生成到别处去了。

如果命令行编不过，先看这三类错误：

1. F1026 File not found: 'RzXxx.pas'—— 搜索路径没覆盖到。检查 .dpk 里 contains 的相对路径，最简单粗暴的办法是把-U指向 Source 的绝对路径。
2. F2063 Could not compile used unit 'RzXxx.pas'—— 单元本身编不过，通常是老代码用了 Berlin 已移除的 API，或者条件宏走错了分支。这时候要把-Q去掉，看第一个报错的具体行号。
3. F2613 Unit 'Vcl.Forms' not found—— 说明 dcc32 读的配置文件不对，或者你在一个没有正确设置环境变量的命令行窗口里执行。用 IDE 自带的 “RAD Studio Command Prompt” 打开命令行，环境变量是配好的。

运行期包编过之后，还有个容易被忽略的动作：把build\bpl\win32加进系统的 PATH，或者在 IDE 的包搜索路径里登记。设计期包在加载时要去加载运行期 BPL，找不到就是那句经典的The project requires package 'xxx' which is not installed。

3.2 设计期包：Install 才算真正注册，Add 只是登记

打开 IDE，走 Component > Install Packages，先点 Add 把设计期包的 .bpl 或 .dpk 加进来，再点 Install。这两步的区别很多人搞不清：Add 只是告诉 IDE“有这么个包”，Install 才会执行包里注册单元的Register过程，把组件图标真正画到面板上。

设计期包的编译配置必须和运行期包完全一致，这是硬约束。所谓“一致”包括：同一个 Config（都是 Release 或都是 Debug）、同一个平台（都是 Win32）、能互相找到对方的 DCU 和 BPL。如果运行期包用命令行按 Release 编的，设计期包在 IDE 里按 Debug 装，大概率会在 Install 那一步报：

Never-build package 'RaizeComponentsVcl' must be recompiled

这句话的字面意思是“这个包被标记为不需要重建，但它的依赖变了”。根因就是两边的编译配置或时间戳对不上。解决办法不是去改什么 never-build 标志，而是把两个包用同一套参数重编一遍。

如果修正版里设计期包的 .dproj 能正常打开，我一般直接在 IDE 里对设计期包做 Build，让它自己去解析依赖；如果 .dproj 已经损坏（修正版常见，因为原作者可能用的是别的 IDE 版本生成的工程），那就退回命令行：

dcc32 -B -Q ^ -DVER310 ^ -U"..\Source;..\build\dcu\win32" ^ -I"..\Source" ^ -N0"..\build\dcu\win32" ^ -E"..\build\bpl\win32" ^ -LU"..\build\bpl\win32" ^ RaizeComponentsVclDesign.dpk

新增的-LU是关键，它指定“链接时去哪里找依赖包的 .dcp/.bpl”。少了它，编译设计期包时就会报找不到运行期包的接口信息。-U里同时挂上 Source 和运行期 DCU 目录，也是为了让设计期包能直接引用到已编译的运行期单元。

3.3 装完的验证：组件面板、Demo、一次干净重建

装完不要急着开你的正式项目，先做三层验证，每层都能定位到不同层面的问题：

第一层，看组件面板。Berlin 里装好后应该出现独立的 Rz 页签，里面是 Rz 前缀的控件图标。如果页签在但图标是灰的，通常是设计期包加载了但注册过程抛了异常，去看 IDE 的模块加载日志。

第二层，新建一个空白 VCL Forms Application，从面板拖一个按钮类控件到窗体上，直接 F9 运行。这一步验证的是“运行期包的 BPL 能被应用程序找到”。如果编译通过但一运行就报错退出，问题在 BPL 的搜索路径上，不在代码里。

第三层，编译 Demos 目录下的示例工程。示例工程通常用了大量控件组合，能一次性把“某个单元没编进去”这类隐性缺失暴露出来。我习惯挑那个控件最多的 Demo 做一次 Rebuild All，因为增量编译会掩盖依赖问题。

// 验证用最小单元：确认命名空间与单元引用都对得上 unit Unit1; interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, RzButton; // 只引一个 Rz 单元，编不过就说明路径没配对 type TForm1 = class(TForm) procedure FormCreate(Sender: TObject); private FBtn: TRzButton; // 动态创建，绕开设计期注册，单独验证运行期 public end;

这段代码的用意是“把设计期和运行期解耦验证”：不通过面板拖控件，纯代码创建，能编过能跑起来，说明运行期包这一侧是干净的；之后面板上再出问题，就一定出在设计期包或注册环节，排查范围直接砍一半。

4. 避坑与排查：五个我实际翻过车的现场

这一章按“现象 → 原因 → 解决”写，全是装老版本第三方包时的共性坑，不针对某个具体控件。

4.1 现象：编译报 F1026 找不到某个 Rz 单元，但文件明明在

原因：修正版的 .dpk 里 contains 段写的是相对路径，原作者机器的目录层级和你解压出来的层级不一样。比如原来写..\..\Source\RzBorder.pas，你解压后少了一层，路径就断了。另一种可能：IDE 的 Library Path 里加了 Source，但你在命令行编译，命令行不读 IDE 的搜索路径。

解决：先确认-U参数指向的是 Source 的绝对路径；如果坚持用 .dpk 里的相对路径，就用文本编辑器把 contains 段的路径统一改成相对于 Packages 目录的层级，改完存盘再编。别在 IDE 里手动一个个改，容易漏。

4.2 现象：设计期包 Add 的时候弹 “requires package which is not installed”

原因：设计期包 requires 的运行期包，IDE 在已安装包列表里找不到。可能是运行期包压根没 Add 进来，也可能是 Add 了但 BPL 的实际位置变了（你重编过，输出到了别的目录）。

解决：Component > Install Packages 里先确认运行期包在列表里并且勾选状态正常；然后检查它的 BPL 路径是否指向当前实际文件。如果路径是灰色的老路径，先 Remove 再 Add 新的。这一步做完再 Install 设计期包。

4.3 现象：组件面板有 Rz 页签，但重启 IDE 后消失

原因：三种可能。一是只 Add 了 .bpl 没点 Install，注册信息没写进去；二是 IDE 以普通权限运行，而之前的注册信息写在需要提权的注册表分支里，写入失败但没报错；三是你装到了另一个 IDE 版本的分支下，Berlin 启动时读的是自己那一支。

解决：确认 Install 按钮点过并且没有报错；把 IDE 关掉，用管理员权限重开一次再装；装完在 IDE 的 Install Packages 列表里确认包前面打了勾。如果还是丢，去注册表里对应 Berlin 的那一支 BDS 键下面看 Known Packages 有没有你的 BPL 路径，没有就是写入失败。

4.4 现象：编译输出被几百条 hint 淹没，真正的 error 找不到

原因：老源码在新编译器下会产出大量H2443 Inline function has not been expanded之类的提示，叠加隐式导入单元的 warning，真正的错误被埋在里面。

解决：命令行加-Q只留错误；或者在 IDE 里把 Hint 和 Warning 的输出关掉（Tools > Options > Editor Options 里没有，得在 Project Options > Compiling 里调提示级别）。我一般先用命令行跑一遍拿到纯 error 列表，再回 IDE 精确定位。

注意：不要为了“让编译干净”去全局关掉 warning，有些 warning 恰恰指向真问题，比如单元隐式导入导致的重复定义。

4.5 现象：卸载后 IDE 启动报 “Cannot load package”，或者重装后出现两套 Rz 页签

原因：卸载时只删了文件没清注册，或者只清了注册没删 BPL，IDE 启动时按注册表里的路径去加载，文件不在就报错。两套页签则是新旧两个版本的 BPL 同时被登记，注册过程执行了两次。

解决：完整卸载走四步——Install Packages 里 Remove 掉设计期包；删掉磁盘上的 BPL 和 DCP；删掉 Library Path 里残留的 Source 和 BPL 目录；检查你项目 .dproj 里有没有硬编码的<DCCReference>指向老的包，有就一并清掉。这四步做完再重装，基本不会出现双份。

5. 从控件面板到业务代码：三个最常用的属性线

装好只是开始，能不能把它用顺手，取决于你对这几类控件的属性组织方式有没有形成肌肉记忆。Raize 的控件命名很规整，前缀统一，属性设计上沿用了 VCL 的老派风格：外观属性集中在FrameColor/Color/HotTrack这一组，布局属性靠Align/Anchors，数据类控件走Items集合。

5.1 列表选择类控件：Items 与状态数组的配合

以带勾选的列表控件为例，最常见的需求是“加载一批条目，让用户勾选，点确定后收集选中项”。这套流程的关键在于批量操作时用BeginUpdate/EndUpdate包起来，否则每加一条都触发一次重绘，条目上到几百条时界面会明显卡顿。

procedure TForm1.LoadItems; var I: Integer; begin RzCheckList1.Items.BeginUpdate; try RzCheckList1.Items.Clear; for I := 1 to 200 do RzCheckList1.Items.Add(Format('通道 %d', [I])); finally RzCheckList1.Items.EndUpdate; // 必须放在 finally，异常时也能恢复重绘 end; end; procedure TForm1.CollectChecked; var I: Integer; List: TStringList; begin List := TStringList.Create; try for I := 0 to RzCheckList1.Items.Count - 1 do // 勾选状态的读取方式以 RzChkLst.pas 里公开的属性声明为准 if RzCheckList1.Checked[I] then List.Add(RzCheckList1.Items[I]); Memo1.Lines.Assign(List); finally List.Free; end; end;

逻辑说明：BeginUpdate/EndUpdate是 VCL 里所有 Items 集合的通用优化手段，原理是临时挂起重绘消息，批量操作完成后再统一刷新。finally里放EndUpdate是必须的，否则中途抛异常会导致控件永久处于不重绘状态，界面看起来像卡死，这种玄学问题排查起来很费时间。

参数说明：Items.Count的遍历用 0 起始，和 VCL 其它列表控件保持一致；勾选状态的访问属性在不同版本的 Raize 里可能叫Checked[]也可能叫State[]，以你手上这版源码的公开声明为准，别照抄别人的代码。

5.2 分页与容器类控件：ActivePage 与延迟创建

带页签的容器控件在业务窗体里用得最多，属性上就两条线：ActivePage控制当前显示哪一页，页签的显示样式由TabStyle之类的枚举属性控制。真正影响体验的是“页面内容什么时候创建”——如果所有页的控件都在窗体创建时一次性初始化，打开窗体就会明显变慢。

我的常用做法是：只初始化当前页，其它页在OnChange事件里首次进入时再懒加载，用一个布尔数组记状态。

procedure TForm1.FormCreate(Sender: TObject); begin FPageLoaded := False; RzPageControl1.ActivePage := RzTabSheet1; InitPage1; // 只初始化首页 end; procedure TForm1.RzPageControl1Change(Sender: TObject); begin if (RzPageControl1.ActivePage = RzTabSheet2) and (not FPageLoaded) then begin InitPage2; // 首次切到第二页才加载数据 FPageLoaded := True; end; end;

逻辑说明：把“页面切换”当作懒加载的触发点，代价是第一次切换有轻微延迟，收益是窗体打开速度明显提升。FPageLoaded这个标志位要放在窗体字段里，不能用局部变量，否则每次切换都会重新加载。

参数说明：ActivePage赋的是页对象本身而不是索引，赋值时机必须在窗体上的页对象已经创建之后，所以放在FormCreate里是安全的；如果你在OnCreate之前就想设定默认页，得用ActivePageIndex。

5.3 高 DPI 与字体缩放：老控件在新 IDE 上的最大隐患

这套组件最初设计的年代，显示器还是 96 DPI 为主，很多控件的内部尺寸是硬编码像素值。Berlin 的 VCL 已经支持高 DPI 缩放，但前提是控件自己响应缩放消息。老控件在 125% 或 150% 缩放的屏幕上，最常见的症状是：文字变大了，控件边框和内边距没跟着变，看着像错位。

处理原则有两条：一是窗体层面打开Scaled，让 VCL 统一按比例缩放；二是布局尽量用Align和Margins，别用绝对坐标堆控件。绝对坐标的窗体在任何缩放下都会散架，这跟用不用第三方控件无关。

procedure TForm1.FormCreate(Sender: TObject); begin Scaled := True; // 允许 VCL 按 DPI 比例缩放窗体与控件 Font.Name := 'Segoe UI'; // 统一字体，避免不同 DPI 下字体替换导致的宽度跳变 Font.Size := 9; end;

逻辑说明：Scaled打开后，VCL 会在窗体创建时按当前 DPI 与设计时 DPI 的比值缩放所有控件的位置和尺寸。字体名统一是必须的，因为不同字体在不同 DPI 下的度量差异很大，混用会出现“这一块挤、那一块空”。

参数说明：如果某些老控件缩放后依然错位，可以单独把它所在的容器Scaled关掉，代价是在高 DPI 下这一块会显得偏小，但至少布局不崩。这是权衡，不是最优解。

6. 多 IDE 共存与彻底清理：一套能重复用的目录纪律

一台机器上同时装两三个 Delphi 版本是很常见的事，同一个组件库要在这几个版本下各装一份，如果输出目录共用，必然互相覆盖。我后来的做法是强制每个“IDE 版本 + 组件版本”组合独占一套产物目录，路径里带版本号，谁也别碰谁：

build\berlin\raize61112\dcu\win32\ build\berlin\raize61112\bpl\win32\ build\tokyo\raize61112\dcu\win32\

配套的编译脚本按目录切换，而不是靠 IDE 里点来点去。这样做的直接好处是：哪天某个 IDE 版本要重装，你只要删掉对应那一整个目录，不会波及另一个版本已装好的包。

清理的时候按“从 IDE 到磁盘”的顺序走，不要反过来。先在 Install Packages 里 Remove 设计期包，勾选状态取消；再去 Library Path 里删掉对应的 Source 和 BPL 目录条目；然后删磁盘上的 BPL、DCP、DCU 三个产物目录；最后检查你手头几个项目的 .dproj，用文本编辑器搜一下包名，把残留的<DCCReference Include="...RaizeComponentsVcl..."/>删掉。这最后一步最容易被忽略，症状是项目打开时提示找不到包，但你在 IDE 里怎么找都找不到这个包的登记记录——因为它藏在项目文件里。

验证是否清理干净，有个简单办法：新建一个空白 VCL 工程，编译。如果这时候还弹找不到某个 Rz 单元或包，说明路径没清完；干净的话，编译应该毫无波澜。

从那以后我每装一次第三方包，都先把 DCU 输出目录单独指出去，装完立刻在同一套目录下做一次全量重建，绝不用 IDE 的增量编译糊弄过去。后悔药这东西，编译期没有，运行期更没有。希望帮到你。

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