🚀 go-pugleaf

"John McGrath [TeamB]" wrote:
> 
> On Thu, 05 Oct 2000 11:41:42 -0500, Joi Ellis wrote:
> 
> > I could try getting the preferred size and increasing it
> > by some amount.
> 
> Unfortunately, the preferred size is what is fixed (500x300).  I looked
> into packing the JFileChooser and then seeing how small the accessory
> component was, and then increasing the size of the JFileChooser by the
> difference.  But it actually sets the size of the accessory to its
> preferred size.  The components are not smaller than requested;  they
> just do not fit in the JFileChooser.

To be pendantic, don't you mean the JFileChooser no longer fits within
the fixed-size JDialog box the display methods are creating?

> 
> One thing that might work would be to lay out the JFileChooser, find the
> largest bottom and right coordinates of the components inside it, and
> then set the preferredSize based on that.  You would have to adjust for
> the bottom and right margins, since that approach would leave no margin.

I'm still unclear on one point:  The code snippet you quoted yesterday
indicated that the dialog's getPreferredSize method returned the
values from the static variables.  So, even if I setPreferredSize with
my desired values, that getter is still going to return the static
constants, right?  Setting the preferred size in my experiments had no
effect on the manufactured dialog box.

One workaround I've played with is to not use the dialog methods at all,
but to lay the bugger out in a JFrame.  But I encountered problems with
it not passing the button presses back to my app. :/  At that point I
figured there had to be a better way.  Maybe there just isn't...

--
Joi Ellis                    Software Engineer
Aravox Technologies          joi@aravox.com, gyles19@visi.com

No matter what we think of Linux versus FreeBSD, etc., the one thing I
really like about Linux is that it has Microsoft worried.  Anything
that kicks a monopoly in the pants has got to be good for something.
           - Chris Johnson