ToolBar 类

Object
  VObject
    Control
      ToolBar

 CLASS ToolBar INHERIT Control

public class ToolBar : Control

工具栏为用户提供了一种选择菜单命令的替代方式。
虽然工具栏看起来更像是一组控件，而不是菜单，但它是作为菜单而不是作为控件构建和操作的。 事实上，菜单、工具栏和按钮生成的事件并没有根本的不同：每个菜单命令、工具栏按钮或按钮都有一个符号名称； 每种类型的事件都调用一个命名方法； 每个都有一个在状态栏中显示的描述(“短帮助”)和一个在选择上下文帮助(Shift+F1)时显示的帮助上下文。
但是，由于工具栏是一个对象，能够生成许多事件，而且，由于它是作为整个窗口的一部分(而不是作为几个按钮)， 它更像是一个菜单而不是一个常规控件。
此外，定义和使用工具栏的标准方式是作为其关联菜单的附属物；这是菜单编辑器生成的结构。
工具栏按钮可以以图标、图标加文本标题或仅文本的形式呈现。
按钮周围的边框提供了几种不同的外观，按钮之间的间隙可以调整。如果工具栏太小，无法显示所有的按钮，可能是因为其所有者窗口太小， 它会自动显示滚动按钮。
工具栏的放置在一定程度上取决于其内容。
例如，只有文本的按钮是长而薄的，因此最好沿垂直边缘堆叠，而不是沿顶部或底部边缘。 只有图标的按钮，没有间隙，沿顶部边缘看起来非常自然。图标和文本按钮，带有一个小间隙，沿底部边缘是有效的。
ToolBar 类还提供了 CoolBar/Band 支持，即带有分隔符带的工具栏(这个例子来自 Internet Explorer 的扁平样式工具栏带)。` 分配工具栏给窗口的方式与分配菜单给窗口的方式相同，通过对 AppWindow:ToolBar() 的赋值。 每个工具栏按钮都与一个菜单命令关联，并生成相应的菜单事件；因此，分配给窗口的菜单和工具栏必须协调。
管理工具栏的最方便的方式是在创建菜单时将其与菜单关联。然后，当菜单分配给窗口时，它的工具栏也会自动分配。 这种自动的方法，与菜单编辑器创建的类定义相匹配，确保工具栏按钮的点击与预期的菜单命令事件相关联。 (这也是加速键表的使用方法。因此，“菜单”实际上是菜单、加速键表和工具栏的组合，所有这些都是协调的，都一起使用。)
可以在任何窗口上放置工具栏，甚至是不能拥有菜单的窗口(例如对话框窗口和嵌套子窗口)。 在这些情况下，分配菜单不会产生可见的菜单，但工具栏仍然是活动的。 还可以将工具栏按钮与未包含在任何菜单中的菜单命令关联，只要菜单命令在 Menu:RegisterItem() 中注册。
工具栏占据窗口的客户区。一些窗口类型会自动适应这种空间冲突，但其他需要显式管理空间。
在业务应用程序中，工具栏最常见的用法是将其附加到shell窗口或数据窗口。 这两种窗口类型都会自动适应工具栏，因此不需要进一步的操作。 数据窗口最有可能是作为 shell 的子窗口使用，或者作为嵌套子窗口；在任何一种情况下，数据窗口都会适应工具栏。
将工具栏放在子窗口上特别有用：它可以将操作与它们应用的数据进行视觉关联。 许多数据窗口可能会使用工具栏按钮，比如插入记录、删除记录、跳过下一个、跳过上一个、转到顶部、转到底部、查找、撤销、剪切、复制和粘贴。
对于一般的顶层窗口、子窗口和对话框窗口，空间管理是开发人员的责任。 对于窗口上的工具栏，这有点棘手，特别是如果允许用户拖动工具栏：可用空间取决于窗口的调整大小和工具栏的放置。 工具栏具有 ToolBar:ClientArea 访问，可以在暴露事件中调用，以确定剩余区域的形状。
似乎工具栏附加到窗口的控制事件的操作是非常明显的：点击打印按钮会向窗口发送一个 #Print 消息。 但是，如果工具栏没有附加到子窗口，而是附加到shell窗口呢？或者如果它附加到子窗口， 但是处理消息的方法属于 shell 窗口？或者工具栏附加到作为嵌套子窗体使用的数据窗口呢？
工具栏在其操作上与菜单是相同的。无论哪个窗口拥有工具栏或菜单，命令事件都首先发送到具有焦点的窗口； 如果它不处理，就会发送到它的所有者，以及它的所有者，直到它被处理。如果没有窗口响应消息，shell 窗口会在其状态栏中显示一条消息。
更准确地说，给定工具栏或菜单命令的符号名称，响应链如下： 焦点窗口是否有一个方法，方法名正确？如果是，就调用它。 检查它的所有者是否有匹配的方法，以及所有者的所有者，依此类推。
如果没有窗口有匹配的方法，消息就会发送到具有焦点的窗口的 MenuCommand() 方法。
默认实现的逻辑如下：如果它是窗口的所有者(如子窗口或子窗体)，就将方法传递给它的所有者； 如果它是应用程序的所有者(如顶层或 shell 窗口)，就检查是否有一个窗口类与该名称匹配，如果有，就实例化它；如果没有，就显示消息。 当然，MenuCommand() 方法可以用不同的逻辑替换(例如，低级 Windows 编程中经常使用的传统 CASE 语句)。
因此，有两种升级链：首先，系统沿着所有权链找到匹配的方法名；然后，它沿着 MenuCommand() 方法的升级链进行升级。 如果没有窗口对方法做出响应，作为最后的手段，就会尝试窗口实例化；否则，它会失败。 这意味着工具栏可以放在 shell 窗口、子窗口，甚至嵌套子窗口上：在任何情况下，它都是活动的，消息会发送到所有窗口， 并沿着所有权链进行传播。 请记住，任何时候只有一个菜单是可见的，具有菜单的子窗口会替换其 shell 的菜单；但工具栏不同，它们可以在任何类型的窗口上都可见。
窗口实例化的技巧意味着，如果我们在窗口编辑器中设计一个窗口，只需将其名称给予某个可见窗口的菜单或工具栏项，就可以打开它。 请注意，存在混淆用户的潜在风险，因为命令可能会引用不同的窗口 (这个问题不仅限于工具栏，也适用于菜单)。
考虑一个订单窗口，其中包含有关订单的信息，以及一个嵌套的子窗口(在浏览视图中)，其中包含订单的行项目。 如果菜单包含一个删除命令，这个命令是指什么？它是删除订单，删除订单及其所有行项目，还是只删除一个行项目？
从技术上讲，问题是清楚的：命令首先发送到具有焦点的最低级别窗口，因此如果用户位于行项目子窗口上，该窗口首先收到命令。 如果它不对其做出响应，订单窗口和后来是 shell 窗口就会收到命令。 但是，从用户的角度来看，这种行为并不明显。问题出在菜单命令或工具栏按钮的标题上：“删除”并不是很清晰。 由于用户可能不知道行项目表是一个子窗口(它看起来只是一个窗口上的表)，因此在不同的位置(取决于光标的位置)获取不同的删除效果可能会令人困惑。 因此，建议菜单命令和工具栏按钮的标签明确和清晰，例如“删除订单”和“删除项目”。 即使更高级别的逻辑根据光标位置和数据禁用命令(例如，只要还有未发货的行项目，删除订单可能会变灰)，标签也应该清晰。

有关适当代码的示例，请使用菜单编辑器生成一个简单的菜单，其中包含工具栏，然后使用窗口编辑器将此菜单分配给一个窗口。