按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
BorderLayout 的中央，那意味着它将充满整个的面板。按钮上的标签将让我们知道我们在CardLayout 上的
那个面板上。
在程序片里，面板卡片上将存放卡片和布局管理器 CL 因为CardLayout 必须组成类，因为当我们需要处理卡
片时我们需要访问这些句柄。
这个程序片变成使用BorderLayout 来取代它的默认FlowLayout，创建面板来容纳三个按钮（使用
FlowLayout），并且这个面板安置在程序片末尾的“North”。卡片面板增加到程序片的“Center”里，有效
地占据面板的其余地方。
当我们增加 BottonPanels（或者任何其它我们想要的组件）到卡片面板时，add（）方法的第一个自变量不是
“North”，“South”等等。相反的是，它是一个描述卡片的字符串。如果我们想轻击那张卡片使用字符
串，我们就可以使用，虽然这字符串不会显示在卡片的任何地方。使用的方法不是使用action（） ；代之使用
first（）、next（）和 last（）等方法。请查看我们有关其它方法的文件。
在Java 中，使用的一些卡片式面板结构十分的重要，因为（我们将在后面看到）在程序片编程中使用的弹出
式对话框是十分令人沮丧的。对于 Java 1。0 版的程序片而言，CardLayout 是唯一有效的取得很多不同的
“弹出式”的窗体。
13。12。5 Gr idBagLayout
很早以前，人们相信所有的恒星、行星、太阳及月亮都围绕地球公转。这是直观的观察。但后来天文学家变
得更加的精明，他们开始跟踪个别星体的移动，它们中的一些似乎有时在轨道上缓慢运行。因为天文学家知
道所有的天体都围绕地球公转，天文学家花费了大量的时间来讨论相关的方程式和理论去解释天体对象的运
行。当我们试图用GridBagLayout 来工作时，我们可以想像自己为一个早期的天文学家。基础的条例是（公
告：有趣的是设计者居然在太阳上 （这可能是在天体图中标错了位置所致，译者注））所有的天体都将遵守规
则来运行。哥白尼日新说（又一次不顾嘲讽，发现太阳系内的所有的行星围绕太阳公转。）是使用网络图来
判断布局，这种方法使得程序员的工作变得简单。直到这些增加到Java 里，我们忍耐（持续的冷嘲热讽）西
班牙的 GridBagLayout 和GridBagConstraints 狂热宗教。我们建议废止GridBagLayout 。取代它的是，使用
其它的布局管理器和特殊的在单个程序里联合几个面板使用不同的布局管理器的技术。我们的程序片看起来
不会有什么不同；至少不足以调整 GridBagLayout 限制的麻烦。对我而言，通过一个例子来讨论它实在是令
人头痛（并且我不鼓励这种库设计）。相反，我建议您从阅读 Cornell 和 Horstmann 撰写的《核心Java》
（第二版，Prentice…Hall 出版社，1997 年）开始。
在这范围内还有其它的：在JFC/Swing 库里有一个新的使用Smalltalk 的受人欢迎的“Spring and Struts”
布局管理器并且它能显著地减少GridBagLayout 的需要。
13。13 action 的替代品
正如早先指出的那样，action（）并不是我们对所有事进行分类后自动为handleEvent（）调用的唯一方法。有
三个其它的被调用的方法集，如果我们想捕捉某些类型的事件（键盘、鼠标和焦点事件），因此我们不得不
过载规定的方法。这些方法是定义在基础类组件里，所以他们几乎在所有我们可能安放在窗体中的组件中都
是有用的。然而，我们也注意到这种方法在Java 1。1 版中是不被支持的，同样尽管我们可能注意到继承代码
利用了这种方法，我们将会使用Java 1。1 版的方法来代替（本章后面有详细介绍）。
组件方法 何时调用
action（Event evt； Object what） 当典型的事件针对组件发生（例如，当按下一个按钮或下拉列表项目被选
中）时调用
keyDown（Event evt； int key） 当按键被按下，组件拥有焦点时调用。第二个自变量是按下的键并且是冗余
的是从evt。key 处复制来的
396
…………………………………………………………Page 398……………………………………………………………
keyup（Event evt； int key） 当按键被释放，组件拥有焦点时调用
lostFocus（Event evt； Object what） 焦点从目标处移开时调用。通常，what 是从evt。arg 里冗余复制的
gotFocus（Event evt； Object what） 焦点移动到目标时调用
mouseDown（Event evt； int x，int y） 一个鼠标按下存在于组件之上，在 X，Y 座标处时调用
mouseUp（Event evt； int x； int y） 一个鼠标升起存在于组件之上时调用
mouseMove（Event evt； int x； int y） 当鼠标在组件上移动时调用
mouseDrag（Event evt； int x； int y ） 鼠标在一次mouseDown 事件发生后拖动。所有拖动事件都会报告给
内部发生了mouseDown 事件的那个组件，直到遇到一次mouseUp 为止
mouseEnter（Event evt； int x； int y） 鼠标从前不在组件上方，但目前在
mouseExit（Event evt； int x； int y） 鼠标曾经位于组件上方，但目前不在
当我们处理特殊情况时——一个鼠标事件，例如，它恰好是我们想得到的鼠标事件存在的座标，我们将看到
每个程序接收一个事件连同一些我们所需要的信息。有趣的是，当组件的 handleEvent（）调用这些方法时
（典型的事例），附加的自变量总是多余的因为它们包含在事件对象里。事实上，如果我们观察
ponent。handleEvent（）的源代码，我们能发现它显然将增加的自变量抽出事件对象（这可能是考虑到在一
些语言中无效率的编码，但请记住 Java 的焦点是安全的，不必担心。）试验对我们表明这些事件事实上在被
调用并且作为一个有趣的尝试是值得创建一个过载每个方法的程序片，（action（）的过载在本章的其它地
方）当事件发生时显示它们的相关数据。
这个例子同样向我们展示了怎样制造自己的按钮对象，因为它是作为目标的所有事件权益来使用。我可能会
首先（也是必须的）假设制造一个新的按钮，我们从按钮处继承。但它并不能运行。取而代之的是，我们从
画布组件处（一个非常普通组件）继承，并在其上不使用 paint（）方法画出一个按钮。正如我们所看到的，
自从一些代码混入到画按钮中去，按钮根本就不运行，这实在是太糟糕了。（如果您不相信我，试图在例子
中为画布组件交换按钮，请记住调用称为super 的基础类构建器。我们会看到按钮不会被画出，事件也不会
被处理。）
myButton 类是明确说明的：它只和一个自动事件（AutoEvent）“父窗口”一起运行（父窗口不是一个基础
类，它是按钮创建和存在的窗口。）。通过这个知识，myButton 可能进入到父窗口并且处理它的文字字段，
必然就能将状态信息写入到父窗口的字段里。当然这是一种非常有限的解决方法，myButton 仅能在连结
AutoEvent 时被使用。这种代码有时称为“高度结合”。但是，制造myButton 更需要很多的不是为例子（和
可能为我们将写的一些程序片）担保的努力。再者，请注意下面的代码使用了Java 1。1 版不支持的 API。
//： AutoEvent。java
// Alternatives to action（）
import java。awt。*；
import java。applet。*；
import java。util。*；
class MyButton extends Canvas ｛
AutoEvent parent；
Color color；
String label；
MyButton（AutoEvent parent；
Color color； String label） ｛
this。label = label；
this。parent = parent；
this。color = color；
｝
public void paint（Graphics g） ｛
g。setColor（color）；
int rnd = 30；