Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / GUI / June 2009

Tip: Looking for answers? Try searching our database.

Frame packing problem with JTextArea containing wrapped text

Thread view: 
<<<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 Magazines

Get 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 ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2010 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.