This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Swing / AWT / SWT and the fly likes Changing the start directory for JFileChooser open dialog Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Changing the start directory for JFileChooser open dialog" Watch "Changing the start directory for JFileChooser open dialog" New topic
Author

Changing the start directory for JFileChooser open dialog

Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2853
    
  11

I'm running a Swing application on Windows that uses a JFileChooser to select a file. When it comes up, it starts in my "My Documents" folder. Is there a way to change this without changing the source code, which I don't have, by changing a system property or environment variable? Looking into the source of the JFileChooser, it seems a define like "-Duser.home=c:/mydir" might work, or at least link the Home button to that directory, but it doesn't. I guess Windows overrides that behavior, but I'm not clear to what.
Sam Gooding
Ranch Hand

Joined: Dec 06, 2013
Posts: 35
Greg Charles wrote:I'm running a Swing application on Windows that uses a JFileChooser to select a file. When it comes up, it starts in my "My Documents" folder. Is there a way to change this without changing the source code, which I don't have, by changing a system property or environment variable? Looking into the source of the JFileChooser, it seems a define like "-Duser.home=c:/mydir" might work, or at least link the Home button to that directory, but it doesn't. I guess Windows overrides that behavior, but I'm not clear to what.


I confirmed that G:\java\>java -Duser.home=G:\ Test definitely causes the JFileChooser to pop up in the G directory rather than my normal home directory . It *should * work for you too. are you overriding user.home somewhere after this invocation perhaps? What version of Windows?
Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2853
    
  11

Well, that's weird. I can't get that to work at all. I'm running Windows 7, with JDK 1.7.0_45. Can I see your test code? Here's what I've been using, but bear in mind that I haven't written any Swing in over a decade.



I've tried various permutations of setting the system property, including:

java -Duser.home=C:\opt TestFileChooser
java -Duser.home="C:\opt" TestFileChooser
java -Duser.home=C:\opt TestFileChooser
java -Duser.home=C:\\opt TestFileChooser
java -Duser.home=C:\\\\opt TestFileChooser
java -Duser.home="C:\opt" TestFileChooser
java -Duser.home="C:\\opt" TestFileChooser


The sysout looks reasonable, but invariably when I open the File Chooser dialog, the starting directory is "c:\greg\Documents", and if I click the home button, it goes to my Desktop folder.
Sam Gooding
Ranch Hand

Joined: Dec 06, 2013
Posts: 35
Compile and run this:



public class PropertyTest{
public static void main(String[] args) {
System.out.println(System.getProperty("user.home"));

}
}


using this invocation:

java -Duser.home=C:\ PropertyTest <-- space of course before PropertyTest

and tell me what it outputs?

This will tell us if the problem is somewhere in your program , i.e. it's being changed somewhere for some reason after the program runs but before the JFileChooser has launched... also.. are you on winXP by any chance?
Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2853
    
  11


c:\temp>java -Duser.home=C:\ PropertyTest
C:\


Actually, my test code was already printing out the value of the user.home property (line 8). It always prints out what I've passed in via the -D parameter. I've noticed though that if I don't pass in a parameter user.home is set to c:\users\greg, not c:\users\greg\Documents, so that's not actually where the JFileChooser is getting its information. The curious thing is why it would be working for you.
Sam Gooding
Ranch Hand

Joined: Dec 06, 2013
Posts: 35
OK. That implies that the JFileChooser constructor is setting the folder it opens to explicitly and not using a system property. The default behavior is to open at user.home:

Conceptually it's :

new JFileChooser(System.getProperty("user.home"));

but we changed the user.home and nothing changed.

That means the program is *at best* constructing a path to open using some property other than user.home. At worst, it's just hard coded into the program as a string, in which case without recompiling the .class files, you can't do much At best it's accessing some other property. You might backdoor a solution by changing what folder MyDocuments points to on the OS. The instructions to do that are here: (for windows 7)

http://windows.microsoft.com/en-us/windows7/redirect-a-folder-to-a-new-location

HTH
Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2853
    
  11

The vendor claims that their program uses the no argument constructor of JFileChooser, and that's definitely what I'm using in my test code. Opening at user.home isn't the default behavior that I'm seeing. Are you using something other than Windows 7? Can I see your test code?
Sam Gooding
Ranch Hand

Joined: Dec 06, 2013
Posts: 35

Here is how I understand this issue.

This is a walk through of the code. It starts in JFileChooser and ends in a class named ShellFolderManager
Starting at JFileChooser no arg constructor



this invokes a constructor in JFileChooser with null as the first argument:



which invokes setCurrentDirectory(null); in JFileChooser:



which in turn invokes getFileSystemView.getDefaultDirectory(); here:







Finally here is the implementation of that get() in ShellFolderManager :

(from: http://pag-www.gtisc.gatech.edu/chord/examples/jdk/sun/awt/shell/ShellFolderManager.java.html)



This is also how it behaves on my machine, so this seems plausible.

This is what I know and how I know it !

Also and just for good measure here is a SCCEE (for anyone with a folder on their system named OPP - Other People's Problems !)
with two lines you can toggle on and off by commenting. One creates a file chooser with no arg the other with the user .home property. Invoking the user.home one with the -D option as before yields the same location as with the no arg constructor. Win 7 / Java 7


HTH!!



Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2853
    
  11

Well, it's just plain weird then. When I step into it, my default directory is being retrieved through sun.awt.shell.Win32ShellFolderManager2, a subclass of ShellFolderManager. It has a very different implementation of the get(String) method, which doesn't look at the user.home system variable at all. I can't figure out why I'm getting that ShellFolderManager and you're not, given the same source code and same versions of Windows and Java. It may stay a mystery though.
Sam Gooding
Ranch Hand

Joined: Dec 06, 2013
Posts: 35
OK if I force the debug to step down into compiled code I get the same trace going into Win32ShellFolder2 as you do. I am not sure what's happening .. meh.. I'll look at ti tomorrow maybe.
Sam Gooding
Ranch Hand

Joined: Dec 06, 2013
Posts: 35
OK reviewing this I'm a little lost as to what your goal was. By defining user.home at the command line, I am able to control where the JFileChooser opens.

Was this not the goal in the first post?
Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2853
    
  11

Yes, that's my one and only goal, at least as far as this thread goes. Setting user.home makes no difference to where my JFileChooser opens. I'm confused why it works for you though. Are you absolutely sure that you are using the no argument constructor for JFileChooser, and not new JFileChooser(System.getProperty("user.home")), as you showed in some of your sample code?
Sam Gooding
Ranch Hand

Joined: Dec 06, 2013
Posts: 35
You need to go into the registry and change this key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal

change it to where you want the JFileChooser to load from.

It has to do with Win32ShellFolder vs Win32ShellFolder2 . Mine works the same as yours. Try this, it will work.

HTH
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10146
    
165

This sounds very much like http://www.coderanch.com/t/517573/java/java/System-getProperty-user-home-unreliable

[My Blog] [JavaRanch Journal]
Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2853
    
  11

@Jaikiran -- I'm not sure that is the same issue. I don't have any inconsistencies about the value of user.home system property. It just doesn't seem that this property is used by the JFileChooser on Windows to determine its default starting directory.

@Sam -- that's good advice, thanks! Unfortunately, modifying the user's registry settings just to make this one tool work better is probably a little extreme. In any case, I've contacted the vendor and they've promised to make the start directory configurable via an environment variable, so that will solve my problem.

Thanks to both of you for your help!
 
GeeCON Prague 2014
 
subject: Changing the start directory for JFileChooser open dialog