File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Swing / AWT / SWT and the fly likes Sharing JFileChooser across classes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Sharing JFileChooser across classes" Watch "Sharing JFileChooser across classes" New topic

Sharing JFileChooser across classes

Jon Swanson
Ranch Hand

Joined: Oct 10, 2011
Posts: 214
The basic structure I used for a GUI is:

which works fine. I have popups in the panels that among other things save information from the panel. At the moment each class (firstPanel and secondPanel) create their own instance of JFileChooser. I've had complaints about this. The users prefer that if they change directories, no matter where in the GUI they request to save a file, the starting directory corresponds to whatever directory they were in last. Fair enough.

I'm not sure what option is the best way to handle this requirement.

1. Create one instance in the top level code and pass it as an argument to the constructors for firstPanel and secondPanel. I've already done this for other objects that need to be shared and it feels a bit kludgy.

2. Create a new class that extends JFileChooser and has a static variable for the current directory. I would assume I then need to override some methods of JFileChooser to set and use this variable for all instances of my extended JFileChooser. Then each class could make their own instance, yet the current directory would be shared. I'm not exactly sure about how to make this happen, so if this is the right way to go, tips for implementing it would be appreciated.

3. Create a singleton class, so that the first call would actually create the instance, but subsequent calls would simply return the existing JFileChooser instance. I've done that before also. I don't want to make this a habit if it's not a good way to go.

Any thoughts, suggestions?
Ulf Dittmer

Joined: Mar 22, 2005
Posts: 42965
I wouldn't bother saving and reusing instances of something as mundane as a JFileChooser. Creating those anew each time you need to use one seems perfectly fine.

Furthermore, you don't need to extend it to make it use the most recently used directory. Your code should store that directory in some variable, and then you can set that using the JFileChooser's setCurrentDirectory method when you create a new one (before showing it to the user). You also need to get the directory name whenever a JFileChooser is dismissed so you can store that in the variable, obviously.
Jon Swanson
Ranch Hand

Joined: Oct 10, 2011
Posts: 214
What I have found is that in this situation:

If I bring up the file chooser by pressing the button and change directories, the file chooser remembers the new directory the next time that it is invoked. No need to set or save anything. The trick is that I have several classes that make up my GUI and if each creates a new file chooser, the first time each class invokes the file chooser, the directory will be the starting directory, not that last directory that something was saved in. This is not what the users want, thus my motivation to use the same file chooser instance across classes or extend file chooser in some way such that instances share the current directory.

If I had a variable, it would need to be available to multiple classes, which is why I was thinking of having that variable maintained by my extended JFileChooser.
I agree. Here's the link:
subject: Sharing JFileChooser across classes
It's not a secret anymore!