Re: Frame packing problem with JTextArea containing wrapped text

John B. Matthews wrote:
In article <h25iia$bbe$1@xxxxxxxx>,
"<<<Klu>>>" <klu@xxxxxxxxxxxxxxxxxxx> wrote:
John B. Matthews wrote:
In article <h247fo$tle$1@xxxxxxxx>,
"<<<Klu>>>" <klu@xxxxxxxxxxxxxxxxxxx> wrote:
This is the result on my system:

http://i43.tinypic.com/2cyo1s7.jpg
Adding ta.setRows(3), I got this:

<http://i41.tinypic.com/6xvo1y.png>

Using ta.setPreferredSize(new Dimension(0, 60)) also works. Moreover, you can add a JTextArea to a JScrollPane, if desired
This is for fairly brief (up to a few lines) instructions, so I don't want a scroll pane. Nor do I want to be fiddling with setRows. What I want is for it to simply work, with frame.pack() and the layout managers doing their jobs properly.

I want, in other words, to simply be able to specify the text to display and have everything work, without needing to specify a magic number somewhere else (such as with setRows) that has to be kept in synch with that text for things to work.

If the text's length is unpredictably variable, JScrollPane works nicely. The default vertical scroll bar policy hides it until needed.

The text's length doesn't vary in any particular instance. It varies from one window to another, but for any given particular JFrame it's a constant. I don't want it scrolling; I want it neatly formatted in a rectangular area and displayed with other things in the frame, WITHOUT anything being cut off, and WITHOUT any scrolling required, OR any need to specify magic numbers to make everything lay out properly. Automatic layout managers were specifically supposed to prevent the need for that sort of messiness.

I'll repeat for the hard of hearing: once instantiated, NONE of these text boxes are changing in size or contents. The text in them is passed in the goddamn CONSTRUCTOR and not subsequently altered. They SHOULD be correctly calculating the sizes they need to be and reporting this to their layout managers. They ARE correctly calculating their actual sizes, as indicated by the text itself not being cut off by the borders of the text areas. They just are NOT correctly calculating their PREFERRED sizes. This is clearly a BUG.

Layout managers were supposed to save us from this kind of thing.

I thought you were using BoxLayout.PAGE_AXIS for that very reason.

And it isn't working because one component -- JTextArea -- stubbornly doesn't provide the correct return value from getPreferredSize under some circumstances.

My SSCCE clearly does all of its work on the EDT, yet clearly exhibits the problem.

Doubtless; I meant to recount my own difficulty in this area. you anomaly is likely something else

It has been demonstrated fairly convincingly to be a bug in JTextArea.getPreferredSize().

I habitually use invokeLater(), rather than invokeAndWait().
For simple initialization, the two seem effectively identical.
I didn't want to use invokeLater in this particular case because then the main method would run off the end presumably before it actually invoked and generated a GUI. If the main method returns with no GUI displayed, the VM has a nasty habit of terminating. :)

The last line executed in the thread invokes setVisible(true) on the frame.

The setVisible(true) is, or should be, executed in the SwingUtilities.invokeLater, not in the main thread.

On the main thread, SwingUtilities.invokeLater is called with a newly constructed Runnable object. Then the main thread immediately exits. At this time, SwingUtilities.invokeLater has probably not done more than put the Runnable on some kind of a queue somewhere. Its own code has not even started to execute yet. No GUI is displayed, or even a single JButton or whatever instantiated yet. So unless the presence of an object on that queue inhibits VM termination, I expect the VM might terminate. Using invokeAndWait instead ensures against that without much additional effort, especially when using an IDE with name completion.
.