简介：面向Delphi与C++ Builder开发者的DevExpress ExpressBars Suite v6.37控件包，用来快速构建工具栏、菜单、状态栏和导航栏等专业界面，适合有Windows桌面开发需求、想深入学习控件源码的中高级程序员。压缩包共912个文件，约9.17MB，以pas/cpp源文件、dpk/bpk工程文件、dfm窗体、res资源及bdsproj演示工程为主，便于直接查看设计布局与编译运行。内置BarsDemo、RibbonNotepadDemo、DockingMegaDemo等示例，覆盖XP主题风格、GDI+绘图、拖放布局、动画效果、国际化等特性，能帮助读者快速掌握界面组装技巧。附带的完整源代码允许深入分析ExpressBars内部机制并根据项目需要裁剪扩展，对提升Delphi/C++ Builder界面开发能力有明显价值。目前已有220人学习下载，适合作为控件应用与二次开发参考。 在Delphi圈子混过一些年头的朋友，对ExpressBars这个名字应该不会陌生。当年很多企业级桌面应用、进销存系统、ERP客户端里，那一排排能拖能拽、能自定义布局的工具栏和菜单，十有八九就是用它做的。这套DevExpress出品的组件，在VCL生态里算得上响当当的招牌货。今天这篇不是官方文档翻译，而是以一个实际用过、折腾过、也靠它交付过项目的开发者视角，聊聊这套“DevExpress ExpressBars Suite v6.37 for Delphi/BCB（含完整源代码）”到底能干什么、怎么入手、有哪些坑，以及“含完整源代码”这几个字背后真正的分量。
1. 这到底是一套什么东西
1.1 它解决的是界面开发里最磨人的那块
先别急着把它当成普通按钮组件集。ExpressBars（后来版本里也叫ExpressToolBar）解决的是Windows桌面程序里工具栏、菜单栏、停靠窗口、快捷菜单这一整套交互体系的问题。在它出现之前，Delphi开发者普遍用TMainMenu、TToolBar之类的原生控件，配合TControlBar或者第三方Dock系统来做界面框架，但效果很勉强——按钮样式难看、停靠逻辑僵硬、用户没法自定义布局，窗口缩放后工具栏排列还会乱掉。
ExpressBars把整个体系重新做了。它提供了一套统一的管理框架，每个逻辑单位都挂在管理器上，工具栏、子菜单、按钮、分割线、带编辑框的组合项，都变成了同一套机制下的可配置对象。最直观的感受就是：用户在运行时右键工具栏就能弹出自定义菜单，自由拖拽、增删按钮、保存布局，这放在当年原生控件上得写一堆底层代码才能做到。
这套组件最核心的价值是它把“界面框架层”的复杂度给封装好了。你不需要去处理Windows消息钩子、WM_NCHITTEST、自绘菜单的各种边缘情况，只需要关注业务逻辑，把按钮和事件挂上去就行。这正是v6.37这个版本在当年能火的核心原因——它第一次让Delphi开发者可以很体面地做出和VB/C++商业软件一样专业的界面。
1.2 v6.37这个版本在历史上的定位
v6.37是DevExpress在2007年前后发布的经典版本，主要面向Delphi 7、Delphi 2005/2006/2007和BCB 6/2006这一批编译器。如果你今天还在维护一个用Delphi 7写的老项目，或者需要接手一个历史遗留的Win32桌面系统，这个版本依然是实际可用的。很多老项目跑了好十几年，界面就是用ExpressBars搭的，新来的同事想改点界面细节，第一件事就得把这套组件的旧版本找出来。
从功能上讲，v6.37已经具备了完整的三件套能力：工具栏/菜单体系（ExpressBars本身）、停靠窗口支持（和ExpressDock配套使用）、以及基础的自定义布局持久化。后来的TdxBarManager属性和事件模型、皮肤体系（ExpressSkins）在版本分支上还分离着，要到更后面的版本才大面积整合。所以如果你用v6.37，安装编译时还需要一并准备ExpressLibrary、ExpressDock等基础包，它们之间有严格的编译依赖顺序。
这时候你就能理解为什么“含完整源代码”对开发者来说是个价值很高的附加项。组件源码对正版用户是开放可用的，你不仅能安装使用，还能在出问题的时候打开源码直接定位到VCL层面的具体实现，这对于排诡异故障、做深度定制，帮助是实打实的。
2. 含完整源代码的真实价值点
2.1 黑盒变白盒，排错效率不是一个量级
用过闭源控件的朋友都有过这种经历：组件在某种极端情况下行为不对，你所有参数都调遍了，还是找不出原因，最后只能去官方论坛发帖等回复，一等就是几天。而带源代码的控件就不一样——你可以在IDE里直接按F7步进跟到组件的Paint过程里，看它到底是哪个坐标算得不对、什么情况下跳错了分支、哪个属性没初始化。这种排错体验和闭源控件完全两回事。
我在实际项目里就遇到过一个问题：ExpressBars的工具栏在切换Windows主题后，按钮文字出现残影，刷新不及时。排查半天无果，最后直接打开dxBar.pas，找到按钮绘制相关的Paint过程，发现它在处理WM_THEMECHANGED消息时没有主动触发Invalidate，只重绘了边框区域。看明白原因后，我甚至不用改组件源码，只需要在自己的窗体里拦截这个消息，主动调用一下工具栏的Refresh就能解决。这种判断，没有源码你根本做不出来。
2.2 深度定制：改源码才是终极方案
虽然ExpressBars本身的属性系统已经比较完善，但在复杂业务场景下总有覆盖不到的地方。比如有的企业客户要求工具栏按钮在禁用状态下也保持半透明可点击、要求菜单项带自定义角标、要求特定停靠窗口在拖拽时做出特殊动画——这些需求靠标准属性往往做不齐。
这时候源码就成了最后的“终极外挂”。我在老项目里为了满足客户的定制需求，直接改过ExpressBars源码里的绘制函数，把默认的渐变样式换成更现代的扁平效果。因为有源码，改动后的包重新编译一次就能生效，代码跟IDE里的其他包也无缝集成。项目维护了几年，这个定制改动的旁路一直稳定运行。说实话，如果当初拿到的是闭源版，这个项目会更吃力，甚至要拿Windows原生控件重写界面层。
2.3 向VCL组件开发的标杆学习
还有一个价值常被忽略：学习。ExpressBars是VCL组件开发设计的教科书级案例。它内部如何处理Windows消息、如何协调重绘、如何设计属性编辑器、如何让上百个组件协同工作、如何兼容不同版本的Delphi/RTL差异，这些代码的工程水准都非常高。对想进阶VCL组件开发的人来说，研读这套源码获取的经验，比看多少本理论上都直接。我自己当年就是借这套源码把VCL的消息分发机制彻底搞通的。
3. 核心体系结构与实践思路
3.1 核心类构成与协作关系
从使用层面看，ExpressBars的核心类主要分成几个层次：
- TdxBarManager：全局管理器，一个窗体上一个，统筹所有bar、item、快捷方式、布局保存/加载。创建后，往里面加TdxBar，再往bar里放TdxBarItem的子类对象。
- TdxBar：一条工具栏或菜单栏载体，可以设置DockTop/DockBottom、浮动、自动隐藏等停靠行为。
- TdxBarItem家族：TdxBarButton（普通按钮）、TdxBarSubMenuItem（子菜单项）、TdxBarCombo（组合框）、TdxBarEdit（编辑框）、TdxBarSeparator（分隔线）等，所有item共用一个统一的事件模型。
- TdxBarManager和TdxBar之间是强关联关系：每个bar都挂在某个Manager名下，item的创建、释放、事件绑定都通过Manager统一管理。
这套设计带来一个直接影响：业务代码不需要维护一个零散的控件数组或指针列表，一切找Manager问就行。在运行时遍历所有bar、读写当前可见性、整体切换布局，都极其顺手。它相当于给你提供了一个标准的“界面组件注册中心”。
3.2 设计期工作流：拖拖拽拽搭出主界面框架
实际做界面时，开发流程大致是这样的：
- 在主窗体上放一个TdxBarManager。
- 在Manager里创建若干条TdxBar，设置Caption和Dock位置。
- 往bar里拖入TdxBarButton，在Click事件里挂业务逻辑。
- 对需要分组的按钮插入TdxBarSeparator，对需要级联的按钮用TdxBarSubMenuItem包一层。
- 用TdxBarManager自带的“自定义对话框”让用户能运行时加/删按钮——这个特性几乎零成本，只要把AllowCustomizing设置为True就行。
- 把布局保存到文件：Manager.SaveToRegistry或SaveToStream，下次启动再Load进来。用户拖出来的习惯布局就保住了。
整个体验就是以拖拽为主、代码为辅。界面的交互框架成型速度非常快，剩下的时间基本都花在业务逻辑上。v6.37的设计期编辑器比较朴素，但胜在稳定，几个关键属性都能直接在设计期预览效果，所见即所得。
3.3 与原生TMenu/Toolbar的取舍
这里给你一个实用参考：什么场景应该继续用原生控件，什么时候应该换ExpressBars。我自己总结过一个很朴素的判断标准——如果界面停留在一两个静态工具栏、不要求用户自定义、没有停靠浮动需求，那原生TToolBar足够，能省掉一层依赖；但只要是稍微成规模的管理类系统界面，尤其是那种工具栏一堆、菜单层级深、还要支持用户调整布局的老式商业应用，上ExpressBars几乎没有悬念。
一套能撑住复杂停靠布局、运行时可定制、明暗皮肤通吃、且源码可改的组件体系，面对交付周期和客户需求变化时，腰杆会直很多。
4. 安装集成实操与版本兼容记录
4.1 环境准备与依赖检查
在动手编译安装之前，务必先确认准备工作：
- 编译器版本：v6.37常见支持Delphi 7/2005/2006/2007和BCB 6/2006。如果是在这些旧IDE里直接装，最省心。需要特别注意的是安装包里按编译器分目录放置的BPL/DCU文件，不要选错目录。
- 基础包顺序：必须先编译ExpressLibrary这类底层运行时包，再编译ExpressDock，最后才能编译ExpressBars自身。顺序错了后面会报出一堆“Unit not found”。
- 路径设置：把源码目录加入Tools > Environment Options > Library里的Library path。这一步漏了，IDE就找不到dxBar.pas对应的dcu，编译直接报错。
- 设计期与运行期包：运行期包（如dxBar_D7.bpl）在运行程序时需要；设计期包（如dclDxBarsD7.bpl）负责把组件注册到IDE里，不勾选的话组件面板上找不到新组件。
4.2 完整安装步骤记录
这里以Delphi 7为例，写一个实际验证过的步骤序列：
- 把安装包解压到无中文/无空格路径，比如D:\DevExpress\ExpressBars。路径里带空格在旧版IDE里偶尔会出诡异问题，尽量避免。
- 打开ExpressBars源码目录下的Packages\Delphi7，找到对应的分组包文件，一般有运行时包和设计期包两个。
- 先打开底层运行时包（比如ExpressLibrary的包文件），点Compile，再点Install。Install后IDE底部会提示组件安装成功。然后再依次编译ExpressDock、ExpressBars的运行时包，最后编译并安装ExpressBars设计期包。
- 切换到安装有ExpressBars工具的页面（比如“DevExpress”标签页），看到TdxBarManager等组件出现，就说明安装已经完成。
- 新建一个空工程，拖一个TdxBarManager到窗体上，把默认生成的bar改成你想要的样式，编译运行，确认没有缺包报错。
4.3 在新版Delphi里沿用旧组件的可能性
如果你今天用的是Delphi XE系列或更新的版本，又想把v6.37的界面代码迁移过来，理论上能编，但非常不推荐直接硬编。旧版源码用到的一些RTL函数在老版本里存在，在新版本里可能改了签名或移动到别的单元；字符串类型演变导致的隐式转换问题也普遍存在。
更实际的做法是保留老项目在老版本IDE里维护，或者把旧界面的ExpressBars升级为DevExpress官方后来的新版ExpressToolBar/ExpressBars套件，再手动把界面对象一一映射过来。v6.37的数据结构事实上并不同后来版本完全兼容，迁移时要做好写转换脚本的心理准备。升级工作的核心方向是：迁移逻辑代码，而不是试图让旧组件适应新工具链。
5. 常见问题与排障实录
5.1 编译与链接报错怎么应对
- 提示某个dx*.pas单元找不到：几乎都是Library path没配好。把ExpressBars的源码根目录和各个子库源码目录都加进去，严谨匹配要编译的版本目录。
- 提示“Cannot load package xxx”：多半是运行时包和设计期包的版本错配或者没编译成功。清空一下编译缓存dcu文件，按顺序重新编译全部包。
- 编译时大量“E2066 Missing operator or semicolon”之类的语法错误：先在包级别上确认编译器版本是否为所支持版本，比如用Delphi 2009强行编译v6.37的包通常就一堆语法错误，因为编译器约束不一致。硬上得不偿失。
5.2 设计期崩溃与运行期闪退
最典型的设计期崩溃点：在窗体上放置TdxBarManager之后，稍微改动属性IDE就报Access Violation。这和v6.37在设计期试图实时重绘、但包加载顺序不对有关。优先确认设计期包是否最后一个安装的，另外把窗体上的其他第三方包先移除，排除影响后再次测试。
运行期闪退中比较常见的还有：窗体析构时Manager已经释放，但子item的事件还引用着外部对象；或者用户自定义布局里存了旧的状态，新版本代码读不到对应的对象。这类问题重点排查代码里是否正确判断了Assigned(TdxButton)再访问，以及在Manager销毁前是否把所有Bar都清空。源码在手时，通常直接断到出错的单元栈里就能定位。
5.3 与皮肤、多显示器环境的坑
老版本的ExpressBars和ExpressSkins的配合不像后来版本那么顺滑。给窗体套用皮肤后，工具栏自绘和皮肤的协调器有时会互相覆盖颜色，出现按钮文字颜色和背景融合、看不清的情况。这时候检查皮肤管理器是否同时加载了ExpressBars的适配器组件。没有适配器的话，工具栏还是用自己的旧自绘，跟皮肤就不在一个频道上。
另外，多显示器环境里如果显示器的DPI设置不一致，v6.37对DPI变化的响应基本没有，工具栏在副屏幕上会显得偏小。这个版本的时代背景决定了它没有适配高DPI缩放，项目若一定要在高分屏上跑，可以把系统的“替代高DPI缩放行为”设为“应用程序”方式，让界面按自身逻辑缩放，至少不会糊成一团。
6. 实操心得与后续扩展建议
用ExpressBars v6.37做了几个项目之后，我最大的心得是：以TdxBarManager为中心的组织方式，天然适合界面结构化。新项目接手时，看代码先从Manager的bar列表展开，就能知道整个界面有哪些入口、哪些按钮绑定了什么事件，比翻几百个事件处理过程高效得多。
如果后续想把它玩得更深，建议从两个方向入手。一是把运行时自定义布局的功能用好：设置AllowCustomizing为True，把用户拖好的布局通过SaveToRegistry持久化到注册表或配置文件里，启动时再Load回来。这类小功能对客户体验提升很大，代码量却很少。二是研究一下TdxBarManager在停靠浮动模式下的行为，在有MDI子窗口的管理系统里，设定停靠区域、浮动工具栏、自动隐藏侧边栏，都靠这块来支撑，做完整后界面专业度会一个档次。
最后还想提醒一句：任何商业项目在使用DevExpress组件时，都要确认好许可授权范围。含源代码的版本让定制和排查方便了很多，但在商业交付时要和授权要求匹配好。技术上的能力边界可以很大，商业上还是应该按规矩来。
我这边的项目现状是：老系统还在用v6.37维护，新的桌面端已经逐步向更现代的方向迁移了，但ExpressBars在经典VCL界面布局管理上的设计理念，我还是很认可的。如果你正在接手类似的老项目，希望这篇里的记录能让你少趟几个我没避开的坑。
本文还有配套的精品资源，点击获取
