Java Forum / GUI / June 2009
Frame packing problem with JTextArea containing wrapped text
<<<Klu>>> - 26 Jun 2009 23:34 GMT To simplify the job of presenting instructions on dialogs, I wrote a static helper function:
public JComponent instructions (String string) { JTextArea ta = new JTextArea(string); ta.setEditable(false); ta.setOpaque(false); // Otherwise it has white background. ta.setBorder(BorderFactory.createBevelBorder(BevelBorder.LOWERED)); return ta; }
With a fairly long instruction string (176 characters) I unfortunately got a very long and narrow text area with all of the text on one line.
OK, I decided, if the screen is wide enough it makes the text area long and thin instead of wrapping. Let's see, is there anything in the JTextArea API that might help force earlier wrapping? Yes, there is!
ta.setColumns(60);
Only problem is, it didn't work.
A little digging around revealed that JTextArea has some unbelievably boneheaded defaults, which are fixed with:
ta.setLineWrap(true); ta.setWrapStyleWord(true);
Now the instruction boxes look great, and the dialog boxes look terrible: the row of buttons at the bottom is cut in half horizontally by the window bottom. The JFrames/JDialogs are packing incorrectly whenever the JTextArea text wraps to use two lines; the windows are being made too short by exactly one line.
Why is this happening? I have frame.pack() after the JTextArea has all of its properties set, including setLineWrap and setWrapStyleWord as well as the text, and after it's been added, directly or indirectly, to the frame's component tree. So the JTextArea should be calculating its minimum dimensions correctly, and the frame.pack() should be taking this into account, but instead it's still treating the JTextArea as if it were only one line high.
What gives?
John B. Matthews - 27 Jun 2009 02:39 GMT > To simplify the job of presenting instructions on dialogs, I wrote a > static helper function: [quoted text clipped - 39 lines] > > What gives? I am unable to reproduce this. Can you supply a short, compilable example?
<http://pscode.org/sscce.html>
 Signature John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
<<<Klu>>> - 27 Jun 2009 03:33 GMT > I am unable to reproduce this. Can you supply a short, compilable > example? Well, the only other thing it could be is that I'm doing something like
frame.pack(); Dimension fs = frame.getSize(); Dimension ds = tools.minDimensions(MAX_FRAME_DIMENSIONS, fs) frame.setSize(ds); frame.setVisible(true);
but the size of the frame I'm seeing is well below MAX_FRAME_DIMENSIONS, so this must be just doing the equivalent of
frame.setSize(frame.getSize())
which ought to be a no-op.
(My minDimensions returns a Dimension whose width is the minimum of the widths of the two arguments, and, separately, height is the minimum of the heights of the two arguments. Used so if I have a large list in a scroll pane or something, the window is not made huge and half off-screen. One or both dimensions of the resulting frame would be close to the screen's width or height if it were not returning the original frame size, unaltered.)
John B. Matthews - 27 Jun 2009 03:44 GMT > > I am unable to reproduce this. Can you supply a short, compilable > > example? [quoted text clipped - 13 lines] > > which ought to be a no-op. I vaguely recall something like this when neglecting to construct the GUI on the EDT.
 Signature John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
Lew - 27 Jun 2009 03:59 GMT >>> I am unable to reproduce this. Can you supply a short, compilable >>> example? "<<<Klu>>>" wrote:
>> Well, the only other thing it could be Almost certainly not the *only* other thing it *could* be.
>> is that I'm doing something like >> frame.pack(); [quoted text clipped - 9 lines] >> >> which ought to be a no-op. You should read the link John B. Matthews provided: <http://pscode.org/sscce.html>
Usually when someone does not provide an SSCCE, the problem lies in the part of the code they didn't show. For example, perhaps it's as John B. Matthews wrote:
> I vaguely recall something like this when neglecting to construct the > GUI on the EDT.
 Signature Lew
<<<Klu>>> - 27 Jun 2009 05:33 GMT >>>> I am unable to reproduce this. Can you supply a short, compilable >>>> example? [quoted text clipped - 20 lines] > You should read the link John B. Matthews provided: > <http://pscode.org/sscce.html> package zzzbugfind;
import javax.swing.Box; import javax.swing.BoxLayout; import javax.swing.JButton; import javax.swing.JFrame; import javax.swing.JPanel; import javax.swing.JTextArea; import javax.swing.SwingUtilities;
public class Main { public static void main(String[] args) throws Exception { SwingUtilities.invokeAndWait(new Runnable() { public void run() { JTextArea ta = new JTextArea("Lorem ipsum dolor" + " sit amet, consectetur adipiscing elit." + " Donec in neque at arcu vestibulum euismod" + " non et nibh. Praesent est sem, consequat" + " ut volutpat nec, tincidunt ut urna. Nam" + " sed nulla ac dui interdum viverra eget eu" + "nisi."); ta.setEditable(false); ta.setLineWrap(true); ta.setWrapStyleWord(true); ta.setOpaque(false); ta.setColumns(60); JButton b = new JButton("foo"); JPanel p = new JPanel(); p.setLayout(new BoxLayout(p, BoxLayout.LINE_AXIS)); p.add(Box.createHorizontalGlue()); p.add(b); JFrame frame = new JFrame(); frame.getContentPane().setLayout(new BoxLayout(frame.getContentPane(), BoxLayout.PAGE_AXIS)); frame.getContentPane().add(ta); frame.getContentPane().add(p); frame.pack(); frame.setVisible(true); } }); } }
This is the result on my system:
http://i43.tinypic.com/2cyo1s7.jpg
John B. Matthews - 27 Jun 2009 14:19 GMT > 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:
<http://java.sun.com/docs/books/tutorial/uiswing/components/editorpane.html>
> > I vaguely recall something like this when neglecting to construct > > the GUI on the EDT. [quoted text clipped - 3 lines] > isEventDispatchThread()) in the middle of the code and the console > spat out a "true" as the window appeared, still with the wrong size. I recall being misled by this not long ago. I had carelessly constructed some components on another thread and others on the EDT. Apparent success (failure) hinged on running on a slow (fast) or single- (multi-) processor host. Cleanly separating the view and model was also essential.
I habitually use invokeLater(), rather than invokeAndWait(). For simple initialization, the two seem effectively identical.
 Signature John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
<<<Klu>>> - 27 Jun 2009 17:48 GMT >> This is the result on my system: >> [quoted text clipped - 6 lines] > 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.
Layout managers were supposed to save us from this kind of thing.
>>> I vaguely recall something like this when neglecting to construct >>> the GUI on the EDT. [quoted text clipped - 8 lines] > single- (multi-) processor host. Cleanly separating the view and model > was also essential. My SSCCE clearly does all of its work on the EDT, yet clearly exhibits the problem.
> 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. :)
John B. Matthews - 27 Jun 2009 23:12 GMT > >> This is the result on my system: > >> [quoted text clipped - 16 lines] > 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.
> Layout managers were supposed to save us from this kind of thing. I thought you were using BoxLayout.PAGE_AXIS for that very reason.
> >>> I vaguely recall something like this when neglecting to construct > >>> the GUI on the EDT. [quoted text clipped - 11 lines] > 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
> > I habitually use invokeLater(), rather than invokeAndWait(). > > For simple initialization, the two seem effectively identical. [quoted text clipped - 3 lines] > 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. Wouldn't that have to fail in order to cause the VM to exit? I see main sleep as the GUI is constructed on the EDT, then it runs to completion, while the EDT waits for new Runnables to enter its queue.
 Signature John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
<<<Klu>>> - 28 Jun 2009 01:02 GMT >>>> This is the result on my system: >>>> [quoted text clipped - 17 lines] > 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. [quoted text clipped - 5 lines] > 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.
John B. Matthews - 28 Jun 2009 04:06 GMT [...]
> It has been demonstrated fairly convincingly to be a bug in > JTextArea.getPreferredSize(). I am able to reproduce this effect:
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4446522>
> >>> I habitually use invokeLater(), rather than invokeAndWait(). For > >>> simple initialization, the two seem effectively identical. [quoted text clipped - 11 lines] > The setVisible(true) is, or should be, executed in the > SwingUtilities.invokeLater, not in the main thread. I'm not seeing where I suggested otherwise. Ah, "it" has an ambiguous antecedent. I should have said, "then main runs to completion, while the EDT waits..."
> 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. IIUC, that (anonymous) Runnable executes on the EDT, which is called AWT-EventQueue-0 in my profiler.
> 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. I think the waiting AWT-EventQueue-0 prevents exit:
<http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.8>
> Using invokeAndWait instead ensures against that without much > additional effort, especially when using an IDE with name completion.
 Signature John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
Knute Johnson - 27 Jun 2009 23:22 GMT > 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. > > Layout managers were supposed to save us from this kind of thing. I want ice cream but I'm not getting it. If you want a JTextArea to lay out easily, set the rows and columns and quit arguing about it. And learn how to use GridBagLayout, once you do it will save you unending grief.
 Signature Knute Johnson email s/nospam/knute2009/
<<<Klu>>> - 28 Jun 2009 01:05 GMT > > 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 [quoted text clipped - 7 lines] > learn how to use GridBagLayout, once you do it will save you unending > grief. How rude.
I want a JTextArea to lay out easily automatically, without me, personally, having to count characters and/or experiment to find the right magic numbers to plug in somewhere. If I wanted to do that I'd use setLayout(null) and absolute positioning like it was mid-1990s Visual Basic code I was writing.
The JTextArea should be able to compute its own number of rows from the text, wrap policy, and number of columns. This should be obvious, even to someone in grade school once he's told what a JTextArea is.
As for GridBagLayout, I don't see how it would help here. The problem is a component misreporting its preferred size. That will screw up any layout manager that has to deal with that component.
<<<Klu>>> - 28 Jun 2009 01:19 GMT >> > I want, in other words, to simply be able to specify the text to >> display [quoted text clipped - 24 lines] > a component misreporting its preferred size. That will screw up any > layout manager that has to deal with that component. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4446522
Sun acknowledged it as a bug, then lied by claiming to have fixed it in Java 5, which they didn't, as has been noted in the comments on that bug, and again here.
I will see if the WindowListener workaround works.
Knute Johnson - 28 Jun 2009 04:38 GMT >>> > I want, in other words, to simply be able to specify the text to >>> display [quoted text clipped - 32 lines] > > I will see if the WindowListener workaround works. If you are using 1.3 or 1.4 this is a bug but it was fixed in 1.5.
 Signature Knute Johnson email s/nospam/knute2009/
John B. Matthews - 28 Jun 2009 04:31 GMT > > > I want, in other words, to simply be able to specify the text to > > > display and have everything work, without needing to specify a [quoted text clipped - 9 lines] > > How rude. Not at all. This was a very mild reproof, and it mentioned ice cream. Rude would be ridiculing someone's disability: impaired hearing, for example.
> I want a JTextArea to lay out easily automatically, without me, > personally, having to count characters and/or experiment to find the > right magic numbers to plug in somewhere. If I wanted to do that I'd > use setLayout(null) and absolute positioning like it was mid-1990s > Visual Basic code I was writing. You have identified a long-standing anomaly in JTextArea. It is vexing but not insurmountable.
> The JTextArea should be able to compute its own number of rows from > the text, wrap policy, and number of columns. This should be obvious, [quoted text clipped - 3 lines] > is a component misreporting its preferred size. That will screw up > any layout manager that has to deal with that component. I am a poor student of GridBagLayout, but I took this suggestion to mean that a flexible layout can be used to compensate for the odd bit of text that overflows an errant preferred size.
 Signature John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
Knute Johnson - 28 Jun 2009 06:24 GMT >>>> I want, in other words, to simply be able to specify the text to >>>> display and have everything work, without needing to specify a [quoted text clipped - 11 lines] > Rude would be ridiculing someone's disability: impaired hearing, for > example. Oh it probably was a little. I write a lot of responses that I delete and I probably should have deleted this one. Sorry Klu.
>> I want a JTextArea to lay out easily automatically, without me, >> personally, having to count characters and/or experiment to find the [quoted text clipped - 8 lines] >> the text, wrap policy, and number of columns. This should be obvious, >> even to someone in grade school once he's told what a JTextArea is. You are right, it should and it doesn't. I've been playing around with this and I can't come up with a good workaround other than calling pack(), setting the preferred size to the preferred size and calling pack() again. I did see on the comments to the bug that some folks found this to not work occasionally. One other possibility is a JLabel but you will have to come up with at least one dimension for it. I like how this works,
import java.awt.*; import javax.swing.*;
public class test extends JFrame { String str = "Four score and seven years ago, our " + "fathers brought forth on this continent a new nation, conceived " + "in liberty and dedicated to the proposition that all men are " + "created equal.";
public test() { setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
setLayout(new GridBagLayout()); GridBagConstraints c = new GridBagConstraints();
JLabel l = new JLabel( "<html><div style=\"width: 200px;\">" + str + "</div>"); l.setBorder(BorderFactory.createLineBorder(Color.RED)); add(l,c); pack(); setVisible(true); }
public static void main(String[] args) { EventQueue.invokeLater(new Runnable() { public void run() { new test(); } }); } }
>> As for GridBagLayout, I don't see how it would help here. The problem >> is a component misreporting its preferred size. That will screw up [quoted text clipped - 3 lines] > that a flexible layout can be used to compensate for the odd bit of text > that overflows an errant preferred size. That's what I meant. And that it doesn't expand the size of components unless you tell it to.
 Signature Knute Johnson email s/nospam/knute2009/
<<<Klu>>> - 28 Jun 2009 07:04 GMT >>>>> I want, in other words, to simply be able to specify the text to >>>>> display and have everything work, without needing to specify a [quoted text clipped - 14 lines] > Oh it probably was a little. I write a lot of responses that I delete > and I probably should have deleted this one. Sorry Klu. Apology accepted.
>>> I want a JTextArea to lay out easily automatically, without me, >>> personally, having to count characters and/or experiment to find the [quoted text clipped - 13 lines] > pack(), setting the preferred size to the preferred size and calling > pack() again. Packing in windowOpened() seems to work as well, and is the documented workaround on Sun's bug page, and the one I'm now using. In fact, I edited a prepareFrame(Frame,String) utility function that I use to slap a title on a frame, center it, force it not to be bigger than the screen, pack it, and show it, adding a window listener that packs the frame again on open, so this should never bother me again. :)
> That's what I meant. And that it doesn't expand the size of components > unless you tell it to. It's shrinking the size of components I'm worried about. :)
Knute Johnson - 28 Jun 2009 16:48 GMT If you want to file a bug on that, I'll vote for it.
 Signature Knute Johnson email s/nospam/knute2009/
<<<Klu>>> - 28 Jun 2009 07:00 GMT >>>> I want, in other words, to simply be able to specify the text to >>>> display and have everything work, without needing to specify a [quoted text clipped - 9 lines] > > Not at all. This was a very mild reproof That it was a reproof at all makes it rude.
>> The JTextArea should be able to compute its own number of rows from >> the text, wrap policy, and number of columns. This should be obvious, [quoted text clipped - 7 lines] > that a flexible layout can be used to compensate for the odd bit of text > that overflows an errant preferred size. That sounds like more magic numbers. In fact, getting desired behavior out of GridBagLayout is one of the Dark Arts, hence my preference for nested BoxLayouts in most cases. When I use GridBagLayout, it's usually with computer-generated(!) constraints, rather than manually-specified ones.
Lew - 28 Jun 2009 07:48 GMT Knute Johnson wrote:
>>>> I want ice cream but I'm not getting it. If you want a JTextArea to >>>> lay out easily, set the rows and columns and quit arguing about it. >>>> And learn how to use GridBagLayout, once you do it will save you >>>> unending grief.
>>> How rude. Knute Johnson wrote:
>> Not at all. This was a very mild reproof
> That it was a reproof at all makes it rude. Not if it was deserved. Anyway, I didn't read it as reproof but as rhetoric - an analogy to make a point. It wasn't even personal, unlike calling people hard of hearing or rude.
 Signature Lew
<<<Klu>>> - 29 Jun 2009 04:26 GMT > Knute Johnson wrote: >>>>> I want ice cream but I'm not getting it. If you want a JTextArea [quoted text clipped - 10 lines] > > Not if it was deserved. But it wasn't.
> It wasn't even personal, unlike calling people hard of hearing or rude. And those were.
Lew - 29 Jun 2009 04:39 GMT Lew wrote:
>> Not if it was deserved.
> But it wasn't. Well, it wasn't a reproof anyway, as I read it, but an analogy.
Lew wrote:
>> It wasn't even personal, unlike calling people hard of hearing or rude.
> And those were. This is a written medium. How could being hard of hearing be relevant?
Not that it's a reproof, but a medical condition.
 Signature Lew
<<<Klu>>> - 29 Jun 2009 06:28 GMT > Lew wrote: >>> Not if it was deserved. > >> But it wasn't. > > Well, it wasn't a reproof anyway But it was.
> Lew wrote: >>> It wasn't even personal, unlike calling people hard of hearing or rude. > >> And those were. [deserved] > > This is a written medium. How could being hard of hearing be relevant? Are you always this literal-minded?
Lew - 29 Jun 2009 06:31 GMT Lew wrote:
>> This is a written medium. How could being hard of hearing be relevant?
> Are you always this literal-minded? No. Do you always scold people?
 Signature Lew
Jarrick Chagma - 29 Jun 2009 12:19 GMT > Lew wrote: >>> This is a written medium. How could being hard of hearing be relevant? > >> Are you always this literal-minded? > > No. Do you always scold people? I think this thread (along with some notable ones on c.l.j.p) proves the old adage that the longer the thread the greater the chance of it deteriorating into a petty name-calling exchange.
 Signature Regards,
Jarrick
------------------------------------ Jarrick.Chagma@your.mind.gmail.com (Lose your mind before emailing me)
John B. Matthews - 29 Jun 2009 15:17 GMT In article <4a48a329$0$2616$5a62ac22@per-qv1-newsreader-01.iinet.net.au>,
> > Lew wrote: > >>> This is a written medium. How could being hard of hearing be relevant? [quoted text clipped - 6 lines] > the old adage that the longer the thread the greater the chance of it > deteriorating into a petty name-calling exchange. I disagree. The deterioration began with name-calling and cursing, ~30% of the way in, as shown here:
<http://groups.google.com/group/comp.lang.java.gui/msg/31fead15d587c69e>
That percentage will necessarily fall as the thread grows. It is the behavior that prolongs the thread, rather than the converse. As the marginal cost of usenet falls toward zero and the ease of filtering improves, I don't see a problem.
Paradoxically, that same OP's research and others' helpful contributions were very instructive.
 Signature John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
Jarrick Chagma - 29 Jun 2009 17:34 GMT > In article > <4a48a329$0$2616$5a62ac22@per-qv1-newsreader-01.iinet.net.au>, [quoted text clipped - 23 lines] > Paradoxically, that same OP's research and others' helpful contributions > were very instructive. You may well be right John but I have not seen too many very large threads (and this thread is not one of them) that remain on topic or which escape at least some degree of name-calling and cursing. I conclude from this that the rate at which these undesirable characteristics appear seems to increase with the size of the thread. It probably stems from frustration that the other person(s) is/are not conceding that your point of view is superior to theirs after much effort convincing them of the opposite. It does indeed depend on the individuals involved and their behaviour in those threads but it rarely happens in much smaller threads IMHO.
 Signature Regards,
Jarrick
------------------------------------ Jarrick.Chagma@your.mind.gmail.com (Lose your mind before emailing me)
John B. Matthews - 29 Jun 2009 20:32 GMT In article <4a48ed24$0$2614$5a62ac22@per-qv1-newsreader-01.iinet.net.au>,
> > In article > > <4a48a329$0$2616$5a62ac22@per-qv1-newsreader-01.iinet.net.au>, [...]
> >> I think this thread (along with some notable ones on c.l.j.p) > >> proves the old adage that the longer the thread the greater the [quoted text clipped - 18 lines] > conclude from this that the rate at which these undesirable > characteristics appear seems to increase with the size of the thread. I can see finding an association, but causality would require stronger evidence.
> It probably stems from frustration that the other person(s) is/are > not conceding that your point of view is superior to theirs after > much effort convincing them of the opposite. Frustration is surely a factor: in this case, over a long standing anomaly in the behavior of a library class; but the very words "concede" and "superior" are loaded. For example, I would not "concede" that Lisp is "superior" to Java; I would "acknowledge" that the power of Lisp macros is "isomorphic" to that of Forth compiling words.
> It does indeed depend on the individuals involved and their behaviour > in those threads but it rarely happens in much smaller threads IMHO. I concede the former. I see plenty of short threads where the flame-bait simply lies fallow.
 Signature John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
<<<Klu>>> - 30 Jun 2009 08:32 GMT > Lew wrote: >>> This is a written medium. How could being hard of hearing be relevant? > >> Are you always this literal-minded? > > No. Do you always scold people? No.
<<<Klu>>> - 27 Jun 2009 05:19 GMT >>> I am unable to reproduce this. Can you supply a short, compilable >>> example? [quoted text clipped - 15 lines] > I vaguely recall something like this when neglecting to construct the > GUI on the EDT. It's not that. I'm pretty careful about these things, but just to double check, I threw a System.out.println(SwingUtilities.isEventDispatchThread()) in the middle of the code and the console spat out a "true" as the window appeared, still with the wrong size.
<<<Klu>>> - 27 Jun 2009 03:50 GMT >> I am unable to reproduce this. Can you supply a short, compilable >> example? [quoted text clipped - 21 lines] > to the screen's width or height if it were not returning the original > frame size, unaltered.) Forget it. Removing the setSize stuff, so the last of the code is just
frame.pack(); frame.setVisible(true);
did not alter things. The button row is still cut in half. Could changing the content pane layout to a PAGE_AXIS BoxLayout have gummed things up?
Nope. Changing it to use a nested JPanel with the BoxLayout inside a content pane left with the default BorderLayout didn't make a difference either.
Making the instructions shorter, so that they all fit on one line, does make the difference though.
It is definitely the JTextArea wrapping that's causing the problem.
With the full instruction text, it has preferred dimensions 684x40. With the reduced instruction text, it still has preferred dimensions 684x40, even though it is one line shorter when displayed.
Clearly the bug is in JTextArea.getPreferredSize().
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|