创建窗口和程序片3

创建窗口和程序片3可视编程和Beans 迄今为止，我们已看到Java对创建可重复使用的代码片工作而言是多么的有价值。最大限度地可重复使用的代码单元拥有类，因为它包含一个紧密结合在一起的单元特性（字段）和单元动作（方法），它们可以直接经过混合或通过继承被重复使用。 继承和多形态性是面向对象编程的精华，但在大多数情况下当我们创建一个应用程序时，我们真正最想要的恰恰是我们最需要的组件。我们希望在我们的设计中设置这些部件就像电子工程师在电路板上创造集成电路块一样（在使用Java的情况下，就是放到WEB页面上）。这似乎会成为加快这种模块集合编制程序方法的发展。 可视化编程最早的成功-非常的成功-要归功于微软公司的Visual Basic（VB，可视化Basic语言），接下来的第二代是Borland公司Delphi（一种客户/服务器数据库应用程序开发工具，也是Java Beans设计的主要灵感）。这些编程工具的组件的像征就是可视化，这是不容置疑的，因为它们通常展示一些类型的可视化组件，例如：一个按惯或一个TextField。事实上，可视化通常表现为组件可以非常精确地访问运行中程序。因此可视化编程方法的一部分包含从一个调色盘从拖放一个组件并将它放置到我们的窗体中。应用程序创建工具像我们所做的一样编写程序代码，该代码将导致正在运行的程序中的组件被创建。 简单地拖放组件到一个窗体中通常不足以构成一个完整的程序。一般情况下，我们需要改变组件的特性，例如组件的色彩，组件的文字，组件连结的数据库，等等。特性可以参照属性在编程时进行修改。我们可以在应用程序构建工具中巧妙处置我们组件的属性，并且当我们创建程序时，构建数据被保存下来，所以当该程序被启动时，数据能被重新恢复。 到如今，我们可能习惯于使用对象的多个特性，这也是一个动作集合。在设计时，可视化组件的动作可由事件部分地代表，意味着任何事件都可以发生在组件上。通常，由我们决定想发生的事件，当一个事件发生时，对所发生的事件连接代码。 这是关键性的部分：应用程序构建工具可以动态地询问组件（利用映象）以发现组件支持的事件和属件。一旦它知道它们的状态，应用程序构建工具就可以显示组件的属性并允许我们修改它们的属性（当我们构建程序时，保存它们的状态），并且也显示这些事件。一般而言，我们做一些事件像双击一个事件以及应用程序构建工具创建一个代码并连接到事件上。当事件发生时，我们不得不编写执行代码。应用程序构建工具累计为我们做了大量的工作。结果我们可以注意到程序看起来像它所假定的那样运行，并且依赖应用程序构建工具去为我们管理连接的详细资料。可视化的编程工具如此成功的原因是它们明显加快构建的应用程序的处理过程-当然，用户接口作为应用程序的一部分同样的好。什么是Bean 在经细节处理后，一个组件在类中被独特的具体化，真正地成为一块代码。关键的争议在于应用程序构建工具发现组件的属性和事件能力。为了创建一个VB组件，程序开发者不得不编写正确的同时也是复杂烦琐的代码片，接下来由某些协议去展现它们的事件和属性。Delphi是第二代的可视化编程工具并且这种开发语言主动地围绕可视化编程来设计因此它更容易去创建一个可视化组件。但是，Java带来了可视化的创作组件做为Java Beans最高级的装备，因为一个Bean就是一个类。我们不必再为制造任何的Bean而编写一些特殊的代码或者使用特殊的编程语言。事实上，我们唯一需要做的是略微地修改我们对我们方法命名的办法。方法名通知应用程序构建工具是否是一个属性，一个事件或是一个普通的方法。 在Java的文件中，命名规则被错误地曲解为设计范式。这十分的不幸，因为设计范式惹来不少的麻烦。命名规则不是设计范式，它是相当的简单：(1) 因为属性被命名为xxx，我们代表性的创建两个方法：getXxx()和setXxx()。注意get或set后的第一个字母小写以产生属性名。get和set方法产生同样类型的自变量。set和get的属性名和类型名之间没有关系。(2) 对于布尔逻辑型属性，我们可以使用上面的get和set方法，但我们也可以用is代替 get。(3) Bean的普通方法不适合上面的命名规则，但它们是公用的。4.对于事件，我们使用listener（接收器）方法。这种方法完全同我们看到过的方法相同：(addFooBarListener(FooBarListener)和removeFooBarListener(FooBarListener)方法用来处理FooBar事件。大多数时候内建的事件和接收器会满足我们的需要，但我们可以创建自己的事件和接收器接口。 上面的第一点回答了一个关于我们可能注意到的从Java 1.0到Java 1.1的改变的问题：一些方法的名字太过于短小，显然改写名字毫无意义。现在我们可以看到为了制造Bean中的特殊的组件，大多数的这些修改不得不适合于get和set命名规则。 首先，我们可看到Bean就是一个类。通常，所有我们的字段会被作为专用，并且可以接近的唯一办法是通过方法。紧接着的是命名规则，属性是jump，color，jumper，spots（注意这些修改是在第一个字母在属性名的情况下进行的）。虽然内部确定的名字同最早的三个例子的属性名一样，在jumper中我们可以看到属性名不会强迫我们使用任何特殊的内部可变的名字（或者，真的拥有一些内部的可变的属性名）。 Bean事件的句柄是ActionEvent和KeyEvent，这是根据有关接收器的add和remove命名方法得出的。最后我们可以注意到普通的方法croak()一直是Bean的一部分，仅仅是因为它是一个公共的方法，而不是因为它符合一些命名规则。用Introspector提取BeanInfo 当我们拖放一个Bean的调色板并将它放入到窗体中时，一个Bean的最关键的部分的规则发生了。应用程序构建工具必须可以创建Bean（如果它是默认的构建器的话，它就可以做）然后，在此范围外访问Bean的源代码，提取所有的必要的信息以创立属性表和事件处理器。 Java 1.1版的映象允许一个匿名类的所有方法被发现。这完美地解决了Bean的难题而无需我们使用一些特殊的语言关键字像在其它的可视化编程语言中所需要的那样。事实上，一个主要的原因是映象增加到Java 1.1版中以支持Beans（尽管映象同样支持对象串联和远程方法调用）。因为我们可能希望应用程序构建工具的开发者将不得不映象每个Bean并且通过它们的方法搜索以找到Bean的属性和事件。 这当然是可能的，但是Java的研制者们希望为每个使用它的用户提供一个标准的接口，而不仅仅是使Bean更为简单易用，不过他们也同样提供了一个创建更复杂的Bean的标准方法。这个接口就是Introspector类，在这个类中最重要的方法静态的getBeanInfo()。我们通过一个类处理这个方法并且getBeanInfo()方法全面地对类进行查询，返回一个我们可以进行详细研究以发现其属性、方法和事件的BeanInfo对象。 BeanDumper.dump()是一个可以做任何工作的方法。首先它试图创建一个BeanInfo对象，如果成功地调用BeanInfo的方法，就产生关于属性、方法和事件的信息。在Introspector.getBeanInfo()中，我们会注意到有一个另外的自变量。由它来通知Introspector访问继承体系的地点。在这种情况下，它在分析所有对象方法前停下，因为我们对看到那些并不感兴趣。 因为属性，getPropertyDescriptors()返回一组的属性描述符号。对于每个描述符号我们可以调用getPropertyType()方法彻底的通过属性方法发现类的对象。这时，我们可以用getName()方法得到每个属性的假名（从方法名中提取），getname()方法用getReadMethod()和getWriteMethod()完成读和写的操作。最后的两个方法返回一个可以真正地用来调用在对象上调用相应的方法方法对象（这是映象的一部分）。对于公共方法（包括属性方法），getMethodDescriptors( ）返回一组方法描述字符。每一个我们都可以得到相当的方法对象并可以显示出它们的名字。 对于事件而言，getEventSetDescriptors()返回一组事件描述字符。它们中的每一个都可以被查询以找出接收器的类，接收器类的方法以及增加和删除接收器的方法。BeanDumper程序打印出所有的这些信息。如果我们调用BeanDumper在Frog类中，就像这样：java BeanDumper frogbean.Frog 通用方法列表包含了不相关的事件或者属性，例如croak()。列表中所有的方法都是我们可以有计划的为Bean调用，并且应用程序构建工具可以选择列出所有的方法，当我们调用方法时，减轻我们的任务。 最后，我们可以看到事件在接收器中完全地分析研究它的方法、增加和减少接收器的方法。基本上，一旦我们拥有BeanInfo，我们就可以找出对Bean来说任何重要的事物。我们同样可以为Bean调用方法，即使我们除了对象外没有任何其它的信息（此外，这也是映象的特点）。 当我们按下鼠标键时，文字被安入BangBean中间，并且如果动作接收器字段存在，它的actionPerformed()方法就被调用，创建一个新的ActionEvent对象在处理过程中。无论何时鼠标移动，它的新座标将被捕捉，并且画布会被重画（像我们所看到的抹去一些画布上的文字）。 main()方法增加了允许我们从命令行中测试程序的功能。当一个Bean在一个开发环境中，main()方法不会被使用，但拥有它是绝对有益的，因为它提供了快捷的测试能力。无论何时一个ActionEvent发生，main()方法都将创建了一个帧并安置了一个BangBean在它里面，还在BangBean中附上了一个简单的动作接收器以打印到控制台。当然，一般来说应用程序构建工具将创建大多数的Bean的代码。当我们通过BeanDumper或者安放BangBean到一个可激活Bean的开发环境中去运行BangBean时，我们会注意到会有很多额外的属性和动作明显超过了上面的代码。那是因为BangBean从画布中继承，并且画布就是一个Bean，因此我们看到它的属性和事件同样的合适。Bean的封装 在我们可以安放一个Bean到一个可激活Bean的可视化构建工具中前，它必须被放入到标准的Bean容器里，也就是包含Bean类和一个表示这是一个Bean的清单文件的JAR（Java ARchive，Java文件）文件中。清单文件是一个简单的紧随事件结构的文本文件。对于BangBean而言，清单文件就像下面这样：Manifest-Version: 1.0Name: bangbean/BangBean.classJava-Bean: True其中，第一行指出清单文件结构的版本，这是SUN公司在很久以前公布的版本。第二行（空行忽略）对文件命名为BangBean.class。第三行表示这个文件是一个Bean。没有第三行，程序构建工具不会将类作为一个Bean来认可。 唯一难以处理的部分是我们必须肯定Name:字段中的路径是正确的。如果我们回顾BangBean.java，我们会看到它在package bangbean（因为存放类路径的子目录称为bangbean）中，并且这个名字在清单文件中必须包括封装的信息。另外，我们必须安放清单文件在我们封装路径的根目录上，在这个例子中意味着安放文件在bangbean子目录中。这之后，我们必须从同一目录中调用Jar来作为清单文件，如下所示：jar cfm BangBean.jar BangBean.mf bangbean这个例子假定我们想产生一个名为BangBean.jar的文件并且我们将清单放到一个称为BangBean.mf文件中。 我们可能会想当我编译BangBean.java时，产生的其它类会怎么样呢？哦，它们会在bangbean子目录中被中止，并且我们会注意到上面jar命令行的最后一个自变量就是bangbean子目录。当我们给jar子目录名时，它封装整个的子目录到jar文件中（在这个例子中，包括BangBean.java的源代码文件-对于我们自己的Bean我们可能不会去选择包含源代码文件。）另外，如果我们改变主意，解开打包的JAR文件，我们会发现我们清单文件并不在里面，但jar创建了它自己的清单文件（部分根据我们的文件），称为MAINFEST.MF并且安放它到META-INF子目录中（代表meta-information）。如果我们打开这个清单文件，我们同样会注意到jar为每个文件加入数字签名信息，其结构如下：Digest-Algorithms: SHA MD5SHA-Digest: pDpEAG9NaeCx8aFtqPI4udSX/O0=MD5-Digest: O4NcS1hE3Smnzlp2hj6qeg= 一般来说，我们不必担心这些，如果我们要做一些修改，可以修改我们的原始的清单文件并且重新调用jar以为我们的Bean创建了一个新的JAR文件。我们同样也可以简单地通过增加其它的Bean的信息到我们清单文件来增加它们到JAR文件中。 值得注意的是我们或许需要安放每个Bean到它自己的子目录中，因为当我们创建一个JAR文件时，分配JAR应用目录名并且JAR放置子目录中的任何文件到JAR文件中。我们可以看到Frog和BangBean都在它们自己的子目录中。 一旦我们将我们的Bean正确地放入一个JAR文件中，我们就可以携带它到一个可以激活Bean的编程环境中使用。使用这种方法，我们可以从一种工具到另一种工具间交替变换，但SUN公司为Java Beans提供了免费高效的测试工具在它们的Bean Development Kit，Bean开发工具（BDK）称为beanbox。（我们可以从处下载。）在我们启动beanbox前，放置我们的Bean到beanbox中，复制JAR文件到BDK的jars子目录中。更复杂的Bean支持 我们可以看到创建一个Bean显然多么的简单。在程序设计中我们几乎不受到任何的限制。Java Bean的设计提供了一个简单的输入点，这样可以提高到更复杂的层次上。这些高层次的问题超出了这所要讨论的范围，但它们会在此做简要的介绍。我们可以在 我们增加更加复杂的程序和它的属性到一个位置。上面的例子显示一个独特的属性，当然它也可能代表一个数组的属性。这称为索引属性。我们简单地提供一个相应的方法（再者有一个方法名的命名规则）并且Introspector认可索引属性，因此我们的应用程序构建工具相应的处理。 属性可以被捆绑，这意味着它们将通过PropertyChangeEvent通知其它的对象。其它的对象可以随后根据对Bean的改变选择修改它们自己。 属性可以被束缚，这意味着其它的对象可以在一个属性的改变不能被接受时，拒绝它。其它的对象利用一个PropertyChangeEvent来通知，并且它们产生一个ProptertyVetoException去阻止修改的发生，并恢复为原来的值。我们同样能够改变我们的Bean在设计时的被描绘成的方法：(1) 我们可以为我们特殊的Bean提供一个定制的属性表。这个普通的属性表将被所有的Bean所使用，但当我们的Bean被选择时，它会自动地调用这张属性表。(2) 我们可以为一个特殊的属性创建一个定制的编辑器，因此普通的属性表被使用，但当我们指定的属性被调用时，编辑器会自动地被调用。(3)我们可以为我们的Bean提供一个定制的BeanInfo类，产生的信息不同于由Introspector默认产生的。(4) 它同样可能在所有的FeatureDescriptors中改变expert的开关模式，以辨别基本特征和更复杂的特征。Bean更多的知识 另外有关的争议是Bean不能被编址。无论何时我们创建一个Bean，都希望它会在一个多线程的环境中运行。这意味着我们必须理解线程的出口。我们会发现有一段称为Java Beans的回顾的节会注意到这个问题和它的解决方案。Swing入门（注释）。：写作本节时，Swing库显然已被Sun固定下来了，所以只要你下载并安装了Swing库，就应该能正确地编译和运行这里的代码，不会出现任何问题（应该能编译Sun配套提供的演示程序，以检测安装是否正确）。若遇到任何麻烦，请访问http:/www.BruceE，了解最近的更新情况。 而这就是Swing将要占领的领域。Swing库在Java 1.1之后面世，因此我们可以自然而然地假设它是Java 1.2的一部分。可是，它是设计为作为一个补充在Java 1.1版中工作的。这样，我们就不必为了享用好的UI组件库而等待我们的平台去支持Java 1.2版了。如果Swing库不是我们的用户的Java 1.1版所支持的一部分，并且产生一些意外，那他就可能真正的需要去下载Swing库了。 Swing包含所有我们缺乏的组件，在余下的部分中：我们期望领会现代化的UI，来自按钮的任何事件包括到树状和网格结构中的图片。它是一个大库，但在某些方面它为任务被设计得相应的复杂-如果任何事都是简单的，我们不必编写更多的代码但同样设法运行我们的代码逐渐地变得更加的复杂。这意味着一个容易的入口，如果我们需要它我们得到它的强大力量。 Swing相当的深奥，这一节不会去试图让读者理解，但会介绍它的能力和Swing简单地使我们着手使用库。请注意我们有意识的使用这一切变得简单。如果我们需要运行更多的，这时Swing能或许能给我们所想要的，如果我们愿意深入地研究，可以从SUN公司的在线文档中获取更多的资料。Swing有哪些优点 当我们开始使用Swing库时，会注意到它在技术上向前迈出了巨大的一步。Swing组件是Bean，因此他们可以支持Bean的任何开发环境中使用。Swing提供了一个完全的UI组件集合。因为速度的关系，所有的组件都很小巧的（没有重量级组件被使用），Swing为了轻便在Java中整个被编写。 最重要的是我们会希望Swing被称为正交使用；一旦我们采用了这种关于库的普遍的办法我们就可以在任何地方应用它们。这主要是因为Bean的命名规则。键盘操作是自动被支持的-我们可以使用Swing应用程序而不需要鼠标，但我们不得不做一些额外的编程工作（老的AWT中需要一些可怕的代码以支持键盘操作）。滚动被毫不费力地支持-我们简单地将我们的组件到一个JScrollPane中，同样我们再增加它到我们的窗体中即可。其它的特征，例如工具提示条只需要一行单独的代码就可执行。 Swing同样支持一些被称为可插入外观和效果的事物，这就是说UI的外观可以在不同的平台和不同的操作系统上被动态地改变以符合用户的期望。它甚至可以创造我们自己的外观和效果。方便的转换 如果我们长期艰苦不懈地利用Java 1.1版构建我们的UI，我们并不需要扔掉它改变到Swing阵营中来。幸运的是，库被设计得允许容易地修改-在很多情况下我们可以简单地放一个J到我们老AWT组件的每个类名前面即可。显示框架 尽管程序片和应用程序都可以变得很重要，但如果在任何地方都使用它们就会变得混乱和毫无用处。 那些想显示它们自己的类将从JPanel处继承并且随后为它们自己增加一些可视化的组件。最后，它们创建一个包含下面这一行程序的main()：Show.inFrame(new MyClass(), 500, 300);最后的两个自变量是显示的宽度和高度。注意JFrame的标题是用RTTI产生的。工具提示 几乎所有我们利用来创建我们用户接口的来自于JComponent的类都包含一个称为setToolTipText(string)的方法。因此，几乎任何我们所需要表示的（对于一个对象jc来说就是一些来自JComponent的类）都可以安放在窗体中：jc.setToolTipText(My tip);并且当鼠标停在JComponent上一个超过预先设置的一个时间，一个包含我们的文字的小框就会从鼠标下弹出。边框 JComponent同样包括一个称为setBorder()的方法，该方法允许我们安放一些各种各样有趣的边框到一些可见的组件上。按钮 Swing增加了一些不同类型的按钮，并且它同样可以修改选择组件的结构：所有的按钮、复选框、单选钮，甚至从AbstractButton处继承的菜单项（这是因为菜单项一般被包含在其中，它可能会被改进命名为AbstractChooser或者相同的什么名字）。 JButton看起来像AWT按钮，但它没有更多可运行的功能（像我们后面将看到的如加入图像等）。在com.sun.java.swing.basic里，有一个更合适的BasicArrowButton按钮，但怎样测试它呢？有两种类型的指针恰好请求箭头按钮使用：Spinner修改一个中断值，并且StringSpinner通过一个字符串数组来移动（当它到达数组底部时，甚至会自动地封装）。ActionListeners附着在箭头按钮上展示它使用的这些相关指针：因为它们是Bean，我们将期待利用方法名，正好捕捉并设置它们的值。按钮组 如果我们想单选钮保持异或状态，我们必须增加它们到一个按钮组中，这几乎同老AWT中的方法相同但更加的灵活。在下面将要证明的程序例子是，一些AbstruactButton能被增加到一个ButtonGroup中。 为避免重复一些代码，这个程序利用映射来生不同类型的按钮组。这会在makeBPanel中看到，makeBPanel创建了一个按钮组和一个JPanel，并且为数组中的每个String就是makeBPanel的第二个自变量增加一个类对象，由它的第一个自变量进行声明 边框标题由类名剔除了所有的路径信息而来。AbstractButton初始化为一个JButton，JButtonr的标签发生失效，因此如果我们忽略这个异常信息，我们会在屏幕上一直看到这个问题。getConstructor()方法产生了一个通过getConstructor()方法安放自变量数组类型到类数组的构建器对象，然后所有我们要做的就是调用newInstance()，通过它一个数组对象包含我们当前的自变量-在这种例子中，就是ids数组中的字符串。 这样增加了一些更复杂的内容到这个简单的程序中。为了使异或行为拥有按钮，我们创建一个按钮组并增加每个按钮到我们所需的组中。当我们运行这个程序时，我们会注意到所有的按钮除了JButton都会向我们展示异或行为。图标 我们可在一个JLable或从AbstractButton处继承的任何事物中使用一个图标（包括JButton，JCheckbox，JradioButton及不同类型的JMenuItem）。利用JLables的图标十分的简单容易（我们会在随后的一个程序例子中看到）。下面的程序例子探索了我们可以利用按钮的图标和它们的衍生物的其它所有方法。 我们可以使用任何我们需要的GIF文件，但在这个例子中使用的这个GIF文件是这编码发行的一部分，可以在www.BruceE处下载来使用。为了打开一个文件和随之带来的图像，简单地创建一个图标并分配它文件名。 一个图标可以在许多的构建器中使用，但我们可以使用setIcon()方法增加或更换图标。这个例子同样展示了当事件发生在JButton（或者一些AbstractButton）上时，为什么它可以设置各种各样的显示图标：当JButton被按下时，当它被失效时，或者滚过时（鼠标从它上面移动过但并不击它）。我们会注意到那给了按钮一种动画的感觉。 注意工具提示条也同样增加到按钮中。菜单 菜单在Swing中做了重要的改进并且更加的灵活-例如，我们可以在几乎程序中任何地方使用他们，包括在面板和程序片中。语法同它们在老的AWT中是一样的，并且这样使出现在老AWT的在新的Swing也出现了：我们必须为我们的菜单艰难地编写代码，并且有一些不再作为资源支持菜单（其它事件中的一些将使它们更易转换成其它的编程语言）。另外，菜单代码相当的冗长，有时还有一些混乱。下面的方法是放置所有的关于每个菜单的信息到对象的二维数组里（这种方法可以放置我们想处理的任何事物到数组里），这种方法在解决这个问题方面领先了一步。这个二维数组被菜单所创建，因此它首先表示出菜单名，并在剩余的列中表示菜单项和它们的特性。 为了预防浪费和冗长的多个Boolean创建的对象和类型标志，以下的这些在类开始时就作为static final被创建：bT和bF描述Booleans和哑类MType的不同对象描述标准的菜单项（mi），复选框菜单项（cb），和单选钮菜单项（rb）。请记住一组Object可以拥有单一的Object句柄，并且不再是原来的值。 这个程序例子同样展示了JLables和JMenuItems（和它们的衍生事物）如何处理图标的。一个图标经由它的构建器置放进JLable中并当对应的菜单项被选中时被改变。 菜单条数组控制处理所有在文件菜单清单中列出的，我们想显示在菜单条上的文件菜单。我们通过这个数组去使用createMenuBar()，将数组分类成单独的菜单数据数组，再通过每个单独的数组去创建菜单。这种方法依次使用菜单数据的每一行并以该数据创建JMenu，然后为菜单数据中剩下的每一行调用createMenuItem()方法。最后，createMenuItem()方法分析菜单数据的每一行并且判断菜单类型和它的属性，再适当地创建菜单项。终于，像我们在菜单构建器中看到的一样，从表示createMenuBar(menuBar)的表格中创建菜单，而所有的事物都是采用递归方法处理的。 这个程序不能建立串联的菜单，但我们拥有足够的知识，如果我们需要的话，随时都能增加多级菜单进去。弹出式菜单 JPopupMenu的执行看起来有一些别扭：我们必须调用enableEvents()方法并选择鼠标事件代替利用事件接收器。它可能增加一个鼠标接收器但MouseEvent从isPopupTrigger()处不会返回真值-它不知道将激活一个弹出菜单。另外，当我们尝试接收器方法时，它的行为令人不可思议，这或许是鼠标单击活动引起的。列表框和组合框 列表框和组合框在Swing中工作就像它们在老的AWT中工作一样，但如果我们需要它，它们同样被增加功能。另外，它也更加的方便易用。例如，JList中有一个显示String数组的构建器（奇怪的是同样的功能在JComboBox中无效！）。最开始的时候，似乎有点儿古怪的一种情况是JLists居然不能自动提供滚动特性-即使那也许正是我们一直所期望的。增加对滚动的支持变得十分容易，就像上面示范的一样-简单地将JList封装到JScrollPane即可，所有的细节都自动地为我们照料到了。滑杆和进度指示条 滑杆用户能用一个滑块的来回移动来输入数据，在很多情况下显得很直观（如声音控制）。进程条从空到满显示相关数据的状态，因此用户得到了一个状态的透视。我最喜爱的有关这的程序例子简单地将滑动块同进程条挂接起来，所以当我们移动滑动块时，进程条也相应的改变JProgressBar十分简单，但JSlider却有许多选项，例如方法、大或小的记号标签。注意增加一个带标题的边框是多么的容易。树 使用一个JTree可以简单地像下面这样表示：add(new JTree(new Object this, that, other);这个程序显示了一个原始的树状物。树状物的API是非常巨大的，可是-当然是在Swing中的巨大。它表明我们可以做有关树状物的任何事，但更复杂的任务可能需要不少的研究和试验。幸运的是，在库中提供了一个妥协：默认的树状物组件，通常那是我们所需要的。因此大多数的时间我们可以利用这些组件，并且只在特殊的情况下我们需要更深入的研究和理解。 下面的例子使用了默认的树状物组件在一个程序片中显示一个树状物。当我们按下按钮时，一个新的子树就被增加到当前选中的结点下（如果没有结点被选中，就用根结节）最重要的类就是分支，它是一个工具，用来获取一个字符串数组并为第一个字符串建立一个DefaultMutableTreeNode作为根，其余在数组中的字符串作为叶。然后node()方法被调用以产生分支的根。树状物类包括一个来自被制造的分支的二维字符串数组，以及用来统计数组的一个静态中断i。DefaultMutableTreeNode对象控制这个结节，但在屏幕上表示的是被JTree和它的相关（DefaultTreeModel）模式所控制。注意当JTree被增加到程序片时，它被封装到JScrollPane中-这就是它全部提供的自动滚动。 JTree通过它自己的模型来控制。当我们修改这个模型时，模型产生一个事件，导致JTree对可以看见的树状物完成任何必要的升级。在init()中，模型由调用getModel()方法所捕捉。当按钮被按下时，一个新的分支被创建了。然后，当前选择的组件被找到（如果没有选择就是根）并且模型的insertNodeInto()方法做所有的改变树状物和导致它升级的工作。 大多数的时候，就像上面的例子一样，程序将给我们在树状物中所需要的一切。表格 和树状物一样，表格在Swing相当的庞大和强大。它们最初有意被设计成以Java数据库连结为媒介的网格数据库接口，并且因此它们拥有的巨大的灵活性，使我们不再感到复杂。无疑，这是足以成为成熟的电子数据表的基础条件而且可能为整提供很好的根据。但是，如果我们理解这个的基础条件，它同样可能创建相关的简单的Jtable。 JTable控制数据的显示方式，但TableModel控制它自己的数据。因此在我们创建JTable前，应先创建一个TableModel。我们可以全部地执行TableModel接口，但它通常从helper类的AbstractTableModel处简单地继承： DateModel包括一组数据，但我们同样能从其它的地方得到数据，例如从数据库中。构建器增加了一个TableModelListener用来在每次表格被改变后打印数组。剩下的方法都遵循Bean的命名规则，并且当JTable需要在DateModel中显示信息时调用。AbstractTableModel提供了默认的setValueAt()和isCellEditable()方法以防止修改这些数据，因此如果我们想修改这些数据，就必须过载这些方法。一旦我们拥有一个TableModel，我们只需要将它分配给JTable构建器即可。所有有关显示，编辑和更新的详细资料将为我们处理。注意这个程序例子同样将JTable放置在JScrollPane中，这是因为JScrollPane需要一个特殊的JTable方法。卡片式对话框 在前部，向我们介绍了老式的CardLayout，并且注意到我们怎样去管理我们所有的卡片开关。有趣的是，有人现在认为这是一种不错的设计。幸运的是，Swing用JTabbedPane对它进行了修补，由JTabbedPane来处理这些卡片，开关和其它的任何事物。对比CardLayout和JTabbedPane，我们会发现惊人的差异。 下面的程序例子十分的有趣，因为它利用了前面例子的设计。它们都是做为JPanel的衍生物来构建的，因此这个程序将安放前面的每个例子到它自己在JTabbedPane的窗格中。我们会看到利用RTTI制造的程序十分的小巧精致再者，我们可以注意到使用的数组构造式样：第一个元素是被置放在卡片上的String，第二个元素是将被显示在对应窗格上JPanel类。在Tabbed()构建器里，我们可以看到两个重要的JTabbedPane方法被使用：addTab()插入一个新的窗格，setSelectedIndex()选择一个窗格并从它开始。（一个在中间被选中的窗格证明我们不必从第一个窗格开始）。 当我们调用addTab()方法时，我们为它提供卡片的String和一些组件（也就是说，一个AWT组件，而不是一个来自AWT的JComponent）。这个组件会被显示在窗格中。一旦我们这样做了，自然而然的就不需要更多管理了-JTabbedPane会为我们处理其它的任何事。 makePanel()方法获取我们想创建的类Class对象和用newInstance()去创建并造型为JPanel（当然，假定那些类是必须从JPanel继承才能增加的类，除非在这一节中为程序例子的结构所使用）。它增加了一个包括类名并返回结果的TitledBorder，以作为一个JPanel在addTab()被使用。 当我们运行程序时，我们会发现如果卡片太多，填满了一行，JTabbedPane自动地将它们堆积起来。Swing消息框 开窗的环境通常包含一个标准的信息框集，允许我们很快传递消息给用户或者从用户那里捕捉消息。在Swing里，这些信息窗被包含在JOptionPane里的。我们有一些不同的可能实现的事件（有一些十分复杂），但有一点，我们必须尽可能的利用static JOptionPane.showMessageDialog()和 JOptionPane.showConfirmDialog()方法，调用消息对话框和确认对话框。Swing更多的知识 这一节意味着唯一向我们介绍的是Swing的强大力量和我们的着手处，因此我们能注意到通过库，我们会感觉到我们的方法何等的简单。到目前为止，我们已看到的可能足够满足我们UI设计需要的一部分。不过，这里有许多有关Swing额外的情况-它有意成为一全功能的UI设计工具箱。如果我们没有发现我们所需要的，请到SUN公司的在线文件中去查找，并搜索WEB。这个方法几乎可以完成我们能想到的任何事。本节中没有涉及的一些要点：更多特殊的组件，例如JColorChooser,JFileChooser,JPasswordField,JHTMLPane（完成简单的HTML格式化和显示）以及JTextPane（一个支持格式化，字处理和图像的文字编辑器）。它们都非常易用。Swing的新的事件类型。在一些方法中，它们看起来像违例：类型非常的重要，名字可以被用来表示除了它们自己之外的任何事物。新的布局管理：Springs & Struts以及BoxLayout分裂控制：一个间隔物式的分裂条，允许我们动态地处理其它组件的位置。JLayeredPane和JInternalFrame被一起用来在当前帧中创建子帧，以产生多文件接口（MDI）应用程序。可插入的外观和效果，因此我们可以编写单个的程序可以像期望的那样动态地适合不同的平台和操作系统。自定义光标。JToolbar API提供的可拖动的浮动工具条。双缓存和为平整屏幕重新画线的自动重画批次。内建取消支持。拖放支持。总结 对于AWT而言，Java 1.1到Java 1.2最大的改变就是Java中所有的库。Java 1.0版的AWT曾作为目前见过的最糟糕的一个设计被彻底地批评，并且当它允许我们在创建小巧精致的程序时，产生的GUI在所有的平台上都同样的平庸。它与在特殊平台上本地应用程序开发工具相比也是受到限制的，笨拙的并且也是不友好的。当Java 1.1版纳入新的事件模型和Java Beans时，平台被设置-现在它可以被拖放到可视化的应用程序构建工具中，创建GUI组件。另外，事件模型的设计和Bean无疑对轻松的编程和可维护的代码都非常的在意（这些在Java 1.0 AWT中不那么的明显）。但直至GUI组件JFC/Swing类显示工作结束它才这样。对于Swing组件而言，交叉平台GUI编程可以变成一种有教育意义的经验。 现在，唯一的情况是缺乏应用程序构建工具，并且这就是真正的变革的存在之处。微软的Visual Basic和Visual C+需要它们的应用程序构建工具，同样的是Borland的Delphi和C+构建器。如果我们需要应用程序构建工具变得更好，我们不得不交叉我们的指针并且希望自动授权机会给我们所需要的。Java是一个开放的环境，因此不但考虑到同其它的应用程序构建环境竞争，而且Java还促进它们的发展。这些工具被认真地使用，它们必须支持Java Beans。这意味着一个平等的应用领域：如果一个更好的应用程序构建工具出现，我们不需要去约束它就可以使用-我们可以采用并移动到新的工具上工作即可，这会提高我们的工作效率。这种竞争的环境对应用程序构建工具来说从未出现过，这种竞争能真正提高程序设计者的工作效率。