|
Swing 工具包提供各种用于创建用户界面的工具和几乎令人眼花缭乱的选项这些选项用于在程序生存期间修改界面小心地使用这些功能可以导致界面能够适应用户的需要并简化交互过程粗心地使用同样的功能可以导致非常混乱或彻底不可用的程序本文介绍动态 UI 的技术和体系并提供有关构建有效的界面的帮助您将修改随 Sun JDK 一起提供的基于 SwingSet 示例应用程序的源代码;此应用程序的 UI 使用许多动态的特性并且可以作为理解它们的极好的起点 禁用小部件 动态 UI 的最简单形式是使不可用的菜单项或按钮变灰的 UI禁用 UI 小部件与禁用所有小部件的方法都是相同的setEnabled() 函数是 Component 类的一个功能清单 显示了禁用按钮的代码 清单 禁用按钮 buttonsetEnabled(false); 正如您看到的十分简单关键问题是何时应该 启用或禁用一个按钮通常的设计决策是当按钮不可用时禁用它例如当一个文件从上一次保存以来还没有被修改时很多程序禁用 Save 按钮(以及任何相应的菜单项) 关于禁用按钮的重要警告是要记住在适当的时候重新启用它们例如如果在单击按钮和按钮的动作完成之间有一个确认步骤即使确认失败也应该重新启用按钮 调整范围 有时应用程序需要动态地调整数值小部件的范围例如 Spinner 或者 Slider这可能比它看起来要复杂许多特别是 Slider 有二级功能 —— 刻度刻度间隔和标签 —— 这些可能需要随着范围的调整而加以调整以避免灾难发生 SwingSet 示例没有进行任何一项调整所以您需要通过把 ChangeListener 连接到一个可以修改其他滑块的滑块来修改它输入新的 SliderChangeListener 类 如清单 所示 清单 更改滑块的范围 class SliderChangeListener implements ChangeListener { JSlider h; SliderChangeListener(JSlider h) { thish = h; } public void stateChanged(ChangeEvent e) { JSlider js = (JSlider) egetSource(); int i = jsgetValue(); hsetMaximum(i); hrepaint(); } }
当创建第三个水平滑块时(最初示例中的滑块在每个单位处带有标记在 和 等处带有标签) 另外还创建了一个新的 SliderChangeListener它把滑块作为构造器参数传递当创建第三个垂直的滑块(范围从 到 )时新的 SliderChangeListener 作为变更监听器添加到它这大致按预期的那样工作调整垂直滑块改变了水平滑块的范围 不幸的是刻度和标签根本不能很好地工作当范围变得不是太大时每五个刻度处的标签能正确地工作但是刻度 处的额外标签很快成为一个可用性问题如图 所示 图 一起运行的标签 更新刻度和标签 明显的解决方案是只要滑块的最大值被更新就在水平滑块上简单地设置刻度间隔如清单 所示 清单 设置刻度间隔 // DOES NOT WORK int tickMajor tickMinor; tickMajor = (i > ) ? (i / ) : ; tickMinor = (tickMajor > ) ?(tickMajor / ) : tickMajor; hsetMajorTickSpacing(tickMajor); hsetMinorTickSpacing(tickMinor); hrepaint();
目前清单 是正确的但是它没有引起画在屏幕上的标签的任何变化必须使用 setLabelTable() 分别设置标签 添加额外一行修复它 hsetLabelTable(hcreateStandardLabels(tickMajor)); 这仍然出现在刻度 处存在最初设置的标签这样的错误当然本来的意图是想在滑块的最右端始终有一个标签可以通过删除旧的标签(在设置新的最大值之前)然后添加一个新的标签达到这一目的此代码 几乎 可以工作 清单 替换标签 public void stateChanged(ChangeEvent e) { JSlider js = (JSlider) egetSource(); int i = jsgetValue(); // clear old label for top value hgetLabelTable()remove(hgetMaximum()); hsetMaximum(i); int tickMajor tickMinor; tickMajor = (i > ) ? (i / ) : ; tickMinor = (tickMajor > ) ? (tickMajor / ) : tickMajor; hsetMajorTickSpacing(tickMajor); hsetMinorTickSpacing(tickMinor); hsetLabelTable(hcreateStandardLabels(tickMajor)); hgetLabelTable()put(new Integer(i) new JLabel(new Integer(i)toString() JLabelCENTER)); hrepaint(); }
如果我已经告诉过您一次那么我就已经告诉您两次了 我使用几乎 的意思是虽然清单 中的代码删除了刻度 处的标签但是它没有在刻度 i 处添加新标签;相反只能看到间隔为 tickMajor 的标签首先此解决方法相当令人讨厌 清单 强迫显示更新 hsetLabelTable(hgetLabelTable());
这个看起来无意义的操作实际上有重大的作用每当设置标签表时就生成滑块的标签没有为了修改对表进行特殊回调所以添加到表中的新值不必产生效果;很显然清单 中的空操作具有使 Swing 知道它必须更新显示的副作用(以免您认为这是我自己发明的请注意最初的 SwingSet 代码包括这样一个调用) 这只留下了一个问题标签出现在滑块的末端这个非常合理的期望有时使两个标签互相直接相邻乃至重叠如图 所示 图 滑块末端的重叠标签 很多解决此问题的方法都是可行的编写自己的代码以使用值来填充标签表并停止以前的序列以便序列中的最后标签与滑块的末端有一些隔离我将把这个作为作业留给您 在许多情况下为了启用和禁用菜单项而限制菜单修改是很实际的此方法容易受到用于禁用项的常规警告的影响避免由于偶然地禁用重要项而使程序处于不可用状态 添加或删除菜单项或子菜单也是可能的修改 JMenuBar 没有这么容易;没有从工具栏上删除和替换单个菜单的接口如果您想修改工具栏(而不是向最右端添加菜单)需要制作一个新的工具栏并用它替换旧的工具栏 修改单个菜单会立即生效;您不必在将菜单连接到工具栏或另一个菜单之前构建一个菜单当需要修改菜单选项的选择时最容易的方法是修改选定的菜单您可能仍然想添加或删除完整的菜单并且这么做并不是特别难清单 显示一个将菜单插入到菜单条中给定索引前的方法的简单示例此示例假定要替换的 JMenuBar 连接到 JFrame 对象但是任何能使您获得和设置菜单条的东西的工作方式都是一样的 清单 把一个菜单插入到菜单条中 public void insertMenu(JFrame frame JMenu menu int index) { JMenuBar newBar = new JMenuBar(); JMenuBar oldBar = framegetJMenuBar(); MenuElement[] oldMenus = oldBargetSubElements(); int count = oldBargetMenuCount(); int i; for (i = ; i < count; ++i) { if (i == index) newBaradd(menu); newBaradd((JMenu) oldMenus[i]); } framesetJMenuBar(newBar); }
上面的代码我不是开始时就试图编成这样;这是最终的版本已经很好地修复过了所以它能够运行并反映一些有趣的怪事初看起来实现此功能的明显方法似乎应该是使用 getComponentAtIndex()但是这种方法已经受到了反对幸运的是getSubElements() 已经足够好为 newBaradd() 而进行到 JMenu 的强制类型转换可能是安全的但是我不喜欢这样getSubElements() 接口不仅对菜单条而且对菜单进行操作菜单可能具有几种类型的子元素JMenu 是可以添加到 JMenuBar 的惟一元素所以必须把元素强制转换为 JMenu 以把它传递到 JMenuBaradd() 方法不幸的是如果将来的 API 修订版允许将除 JMenu 类型之外的元素添加到 JMenuBar就不再需要把返回的元素强制转换 JMenu了 清单 中的代码反映了另外一个相当微妙的界面怪事;菜单数必须提前缓存起来当把菜单添加到新的菜单条时它们从旧的菜单条中被删除虽然看起来相似但是清单 中的代码不能工作因为循环提前结束了: 清单 循环结束太早 // DOES NOT WORK for (i = ; i < oldBargetMenuCount(); ++i) { if (i == index) newBaradd(menu); newBaradd((JMenu) oldMenus[i]); }
清单 中的循环只复制一半数量的菜单例如如果开始菜单条上有 个 菜单它复制前面的两个菜单复制完第一个菜单以后 i 的值为 并且 getMenuCount() 返回 ;在复制完第二个菜单以后i 的值为 并且 getMenuCount() 返回 因此循环结束我没有找到任何介绍通过向菜单条添加菜单从而从另一个菜单条删除菜单这样的特性的文档因此可能不是有意这样但是它很容易达到这个目的 从菜单条删除菜单稍微容易一些;只是把所有其他的菜单从旧的菜单条复制到新的菜单条就完成了删除菜单很容易! 如果界面使用了很多动态菜单更新创建一组菜单条并在它们之间切换而不是一直动态地更新它们也许会更好一些但是如果如此快地改变菜单可能会使用户完全发疯 勘误在本文的草稿阶段我忽略了 JMenuBar 类的继承方法的列表其实它有 remove 和 add 方法可以用来在指定的索引处进行删除和插入另外一个教训是查看继承的方法而不仅仅是特定于类的方法 调整窗口大小 所幸的是对于大多数情况窗口大小调整是自动进行的但是需要考虑调整大小产生的一些影响在非常小的窗口中按钮条菜单条和类似功能可能变成有问题的管理程序自身的图形面板需要响应调整大小事件让 Swing 处理对 UI 元素的包装但是要密切注视组件的大小;不要获取一次组件的尺寸然后就一直使用这些值 更微妙的地方是一些设计决策(例如滑块上刻度的密度)可能被适度地更新以响应窗口大小调整事件 像素宽度的滑块不能具有像 像素宽度的滑块那样多的可读标签您可能想通过添加全新的有用功能来让 UI 更进一步用在大型显示器上 但是在多数情况下可以忽略窗口大小调整您不应该做的是不必要地阻止或重写它布局代码中的窗口一侧的便捷工具不是必需的最小的窗口大小可能是无可厚非的但是要让人们能把窗口调整到他们所需要的大小 一般原则 Swing 工具包在 UI 设计方面提供了很大的灵活性如果小心地使用动态更新界面的选项能够极大地简化该界面;例如只有应用菜单的选项时用户才能容易地显示菜单 不幸的是一些 API 的特性可能使此方法产生一些离奇的行为并且副作用和相互影响并不总是像您期望的那样记录下来如果您有使用动态界面的想法就要准备在调试上花费一些额外的时间您可能从 Swing 库的困境中走出来并发现自己需要处理出人意料的行为和/或 bug 不要让缺乏明显的实现让您气馁像本文的 JMenuBar 示例所显示的即使当 API 不支持某个任务时您也能自己实现它虽然有一点间接 尽量不要走极端当动态 UI 让用户清楚它们的固有限制时它们才能最好地发挥作用理想的情况是用户甚至可能不会注意到界面变化如果他们能够使用程序的 Object 菜单的惟一时刻是当他们使某个对象被选择时那么其余的时间他们将不会介意不存在该菜单 另一方面如果存在这种可能性用户不能猜测出一个选项不可用的原因这时让用户尝试操作并获得包含信息的消息也许会更好这对于一些操作尤其重要如果保存选项被禁用而我想保存数据那么这不会发生作用程序可能认为已经保存了数据但是为什么不让我无论如何都保存它呢?如果存在不能保存文件的特殊原因我可能想知道是什么原因 尽管研究了很多年界面设计在很多方面仍旧是一个较新的领域只进行了很少的试验动态改变 UI 是一个很好的特性能够使 UI 更清晰更简单和反应更迅速添加动态特性需要从几分钟的工作到大量时间的花费不等 |
