I have a problem in changing the location of the accessory component in a filechooser.
I customized a save file dialog by putting a check box in the accessory component of the file chooser. But the position of the check box is not good, it is really ugly.
Can I move the accessory component to be underneath the file pane? How to do it?
Or if you have other solution to do the same thing, also welcome.
Thank you guys.
I using following code to add the check box:
JFileChooser fc = new JFileChooser(file)
JPanel accessory = new JPanel();
JCheckBox isOpenBox = new JCheckBox("Open file after saving");
accessory.setLayout(new BorderLayout());
accessory.add(isOpenBox, BorderLayout.SOUTH);
fc.setAccessory(accessory);
In this screenshot, the position of the check box is not good.
This screenshot is the exactly effect I want.
The "right" way would be to build a new UI/Look and Feel delegate which meet your requirements. The problem is, the details you need to do this (in an OO way) are hidden, either
private
with no public/protected accessor or defined locally...this is a major problem with most of the L&F delegates...thanks guys...So, you'd end up copying and pasting the entire class, just so you can add this one feature...and you'd need to do this for EVERY platform you wanted to support...
The "less than optimal" way, is to ferret around within the
JFileChooser
and pull out those elements you need to "retrofit" your requirements. This is messy, it's error prone, it makes assumptions and will break very, very easily.Personally, if I was to go down this particular track, I would create a utility class which provides a simple
public
,static
method which would allow me to pass an instance ofJFileChooser
and have it, based on the current platform (and/or the current look and feel), make the changes for me...or a factory class that could auto generate aJFileChooser
modified to meet those requirements...but this is just an idea...Let me re-iterate this, this is a very bad idea to a very poor design problem and is meant to demonstrate: 1- The problems with trying to modify a look and feel; 2- The problems and issues you will face in attempting to make this work the way want it to...
And no, I'm not proud...need to go wash my eyes and brain out with bleach...icky...
Updated with Mac Support
And for those who would like a Mac version...
This just further highlights the "flakiness" of this approach, it won't take much to break it...
Updated with
Locale
based searchingThis uses the
FileChooser.filesOfTypeLabelText
UIManager.getString
to look up the text of theFile Format:
key, which in theory, should make it a (slightly) better cross platform solution...at least it makes it work better on the mac...This also demonstrates the mess of having to start to support multiple OS...Since I only have two...
Updated with reflection...
Since I'm already going to programmer hell for the previous "hacks", I might as well as throw in an example of using reflection to find the fields.
Now, there are a number of ways you might do this, you could list all the fields by type, for example and inspect various properties to determine what you want. This would be used when you don't know the actual field name OR, if you have access to the source code, you can look up the field names directly, as is done in this example
Remember: Just because you can do something, doesn't mean you should!