Swing小结
常用布局
流式布局：从左到右一次显示
边框布局：东西南北中，在控制大小时从上往下或从左到右控制，用setPreferredSize控制
盒子布局：可以用BoxLayout或Box，控制大小用setMaximumSize控制大小，这个布局可以沿X或Y方向很好的控制多个控件布局
这三种布局组合可以实现大部分需求
网格，网袋暂时还没怎么用，不喜欢用
卡片布局：这个布局对于某些特定的效果采用，一般也很少用
使用JTable第一次遇见没法显示表头，在放入顶层容器或在使用一些布局时需用JScrollPane包装，不然无法显示表头
在Panel中添加或移除组件时，该Panel需调用validate方法以显示新的组件，多次添加移除
，如面板之间反复切换需调用repaint方法，但调用
repaint方法时需要注意，需要重绘某个组件就用XX.repaint（），不要直接调用repaint，这样会造成不必要的重绘
使用AWT和Swing需注意：
http://java.sun.com/products/jfc/tsc/articles/painting/index.html
AWT Painting Guidelines
The AWT provides a simple callback API for painting components. When you use it, the following guidelines apply:
For most programs, all client paint code should be placed within the scope of the component's paint() method.
Programs may trigger a future call to paint() by invoking repaint(), but shouldn't call paint() directly.
On components with complex output, repaint() should be invoked with arguments which define only the rectangle that needs updating, rather than the no-arg version, which causes the entire component to be repainted.
Since a call to repaint() results first in a call to update(), which is forwarded to paint() by default, heavyweight components may override update() to do incremental drawing if desired (lightweights do not support incremental drawing)
Extensions of java.awt.Container which override paint() should always invoke super.paint() to ensure children are painted.
Components which render complex output should make smart use of the clip rectangle to narrow the drawing operations to those which intersects with the clip area.
Swing Painting Guidelines
Swing programs should understand these guidelines when writing paint code:
For Swing components, paint() is always invoked as a result of both system-triggered and app-triggered paint requests;update() is never invoked on Swing components.
Programs may trigger a future call to paint() by invoking repaint(), but shouldn't call paint() directly.
On components with complex output, repaint() should be invoked with arguments which define only the rectangle that needs updating, rather than the no-arg version, which causes the entire component to be repainted.
Swing's implementation of paint() factors the call into 3 separate callbacks:
paintComponent()
paintBorder()
paintChildren()
Extensions of Swing components which wish to implement their own paint code should place this code within the scope of the paintComponent() method (not within paint()).
Swing introduces two properties to maximize painting efficiency:
opaque: will the component paint all its bits or not?
optimizedDrawingEnabled: may any of this component's children overlap?
If a Swing component's opaque property is set to true, then it is agreeing to paint all of the bits contained within its bounds (this includes clearing it's own background within paintComponent()), otherwise screen garbage may result.
Setting either the opaque or optimizedDrawingEnabled properties to false on a component will cause more processing on each paint operation, therefore we recommend judicious use of both transparency and overlapping components.
Extensions of Swing components which have UI delegates (including JPanel), should typically invoke super.paintComponent() within their own paintComponent() implementation. Since the UI delegate will take responsibility for clearing the background on opaque components, this will take care of #5.
Swing supports built-in double-buffering via the JComponent doubleBuffered property, and it defaults to true for all Swing components, however setting it to true on a Swing container has the general effect of turning it on for all lightweight descendents of that container, regardless of their individual property settings.
It is strongly recommended that double-buffering be enabled for all Swing components.
Components which render complex output should make smart use of the clip rectangle to narrow the drawing operations to those which intersect with the clip area.
