• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Sharing JFileChooser across classes

Ranch Hand
Posts: 251
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
Posts: 43016
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 251
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
You're not going crazy. You're going sane in a crazy word. Find comfort in this tiny ad:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic