The drawing model of Swing is something I've been working with and frustrated by. In cases where you are not using a layout manager, it's really necessary to move things around by hand. This would be nice if the drawing model was 
For setting the size of a component, you call setSize(). Unless the component is in a LayoutManager, in which case you have to call setPreferredSize(). If the worst comes to the worst, you can always setBounds() or setInsets(), both fully explained.

For instance, repainting a panel involves repaint(). Unless you add to it, in which case you have to call validate(). Calling invalidate() doesn't do seem to do anything.  
[?] of which are still unclear.

This is really frustrating.

----

Structured documents and structured graphics can be viewed as two different things, as different as TeX and MacDraw, or book printing and video animation.  A lot of GUI tools offer a singular solution to span both. But that can complicate the debugging of more Cartesian graphical applications.

-- ScottJohnston

----

Part of the problem involved in Swing is that inherited classes have the assumption that they are implicitly understood. For instance, JPanel inherits from Panel, therefore all the methods overridden in JPanel are like Panel "only different".

I've been making progress though.

When you make a change to a component, you invalidate the _component_ and validate the _container_ (I was invalidating the container before).

Never override repaint(), but override paintComponent() instead.

setBounds() does the same thing as setSize() and setLocation() together.

I'm still having problems with faking a layout manager, but this will be worked out in the fullness of time.

''Loads of useful information about layout managers is available at the "Layout Manager Launch" site: http://www.softbear.com/people/larry/javalm.htm''

----

I would suggest looking the source of a LayoutManager to see what ''it'' uses. 
CardLayout might be the best choice as the geometry should be the simplest. Of 
course, it sounds like you've figured out some of the critical pieces. (Sorry, 
I was unable to save changes to the page when you first posted it.) 
-- KielHodges

----

This is turning more and more into a LogBook of Swing problems I run into.

I'm now working on tying a JTree together with a JTable. The first try is based off the JTreeTable implementation on the Swing Connection. Using a JTree as a renderer is far too slow and doesn't handle updates well, so I wired together a model which implemented both TreeModel and TableModel methods and then SplitPaned a Tree and a Table together, looking at the same model.

Problem: In order to make the table work accurately with the JTree, it's necessary to get the number of visible rows in the JTree. getRowForPath works for a single node. But it's a real pain if nodes are inserted in the model, because I don't know if they're visible or not (because they're "model" and not "view"). Which means I have to iterate through nodes. Large amounts of iteration kill Java, whether or not the methods exist in practice or not.

----

So the solution to getting the number of display rows is in the UI class as _tree.getUI().getRowCount().

I would estimate that most of my bugs right now come not from lapses in logic, but in misreading or overlooking parts of the documentation. I'm not sure what I can do about this.

----

Have you seen JTreeTable2 on the Swing Connection? DionGillard

----

I have, and while I like the idea, the problem is that using a tree as a renderer is a canard - it sounds great, but in practice is waaaay too slow to actually be useful. I tried it on my computer, and just expanding a row took 3 or 4 seconds.  

I'm still having problems with repaints not happening when they should, but the speed is good. It may be broken, but it's fast! :-)

----
CategoryJava