I can't respond to the rest yet (I might have time later), but I can at least speak to this:
At 10:52 AM 10/26/2001 -0400, [EMAIL PROTECTED] wrote: >Later, after posting, in desperation I finally replaced the above line >with the crazy-looking > > scrollPane = new JScrollPane(list); > scrollPane.setPreferredSize(scrollPane.getPreferredSize()); > >and this seems to work, even after resizing, and with a functional >message bar. > >In other words, explicitly setting the preferredSize (only once) to >the value it supposedly *already has* causes the behavior to change. >This gem is also completely undocumented, as far as I can tell. A quick explanation of the preferred size mechanism, as I understand it: By default, the preferred size of any JComponent is determined by its UI delegate. UI delegates include javax.swing.plaf.ComponentUI and its subclasses. Some background: a while back I posted an explanation of Swing's MVC architecture, and said that Swing is actually more M-VC than M-V-C. Well, the VC is implemented by the UI delegates, and consequently the Swing architecture is often characterized as model-delegate. One of the methods a delegate has is getPreferredSize. Unlike JComponent.getPreferredSize, ComponentUI.getPreferredSize takes a JComponent parameter. It's then supposed to return the preferred size of that JComponent. This often varies as the component's contents change. The delegates do this because they handle the view, and so it's their job to know. Moreover, different look-and-feels may require different preferred sizes for components. Each L&F is typically handled by its own suite of UI delegates. Look in the source code jar that comes with JDK, and you'll see a bunch of classes that look like MetalSomethingUI, WindowsSomethingUI, MotifSomethingUI; those are the UI delegates for each L&F. (Sometimes the UI delegate will return null as a prefsize, in which case there's yet another fall-back rule to get it, but I won't go into that here.) Then we have JComponent.setPreferredSize. This allows UI designers to ignore whatever the UI delegates say should be the preferred size. IMO this is an impure hack, since it works only for "expected" L&Fs, fonts, and other UI settings, and hence it's not robust to the same degree as the base architecture. OTOH the robust solution (writing a new UI delegate) requires a lot of effort from the programmer, and this "hack" isn't particularly egregious if the programmer is in fact able to force a certain L&F and so forth. All setPreferredSize does is record the size passed in a field, and notify interested classes of the change. Later, getPreferredSize will return that size. (You can pass null to make the JComponent go back to asking the UI delegate.) Good place for more info: Swing, Robinson & Vorobiev, sections 1.4 et al. This is why that setPreferredSize call is working; it's setting the preferred size to something that will never change. _______________________________________________ Swing mailing list [EMAIL PROTECTED] http://eos.dk/mailman/listinfo/swing
