File browser

[Flick]

Hi,

I'm developing an application that needs to open a file but I can't
find out how to bring up that normal windows so that I can choose a
file I want to open.

Can anyone help me?

Thanks

Flick

 

[Knute Johnson]

Hi,

I'm developing an application that needs to open a file but I can't
find out how to bring up that normal windows so that I can choose a
file I want to open.

Can anyone help me?

Thanks

Flick

JFileChooser

 

[Peter Duniho]

JFileChooser

Which reminds me that I forgot to switch my file open/save dialog from the
AWT FileDialog to the Swing JFileChooser when I went through and changed
everything else to be Swing-based.

So I did that, and ran into a problem when displaying the dialog for
saving a file: I can set via code the initial filename in the dialog, or
of course the user can click on a file and that will set the filename.
But unfortunately, this filename is not preserved if the user changes
directories in the file chooser. It's reset to an empty state as soon as
one tries to change directories (e.g. descend into a sub-directory from
the default user location).

This is not normal behavior for any OS-built-in file choosers I've seen,
and it surprised me that the JRE version would do that. I'm wondering if
there's something I've overlooked in the configuration of the JFileChooser
that is causing this to happen. Is there some specific setting that would
allow the filename to be preserved as the user navigates through the
directory structure?

(The AWT FileDialog of course uses the built-in file chooser dialog, and
so works more correctly. Unfortunately, it doesn't offer as flexible file
filtering features as the JFileChooser, so if I can get the JFileChooser
to work in a more usable way I'd prefer to do that).

Pete

 

[John W. Kennedy]

Which reminds me that I forgot to switch my file open/save dialog from
the AWT FileDialog to the Swing JFileChooser when I went through and
changed everything else to be Swing-based.

So I did that, and ran into a problem when displaying the dialog for
saving a file: I can set via code the initial filename in the dialog, or
of course the user can click on a file and that will set the filename.
But unfortunately, this filename is not preserved if the user changes
directories in the file chooser. It's reset to an empty state as soon
as one tries to change directories (e.g. descend into a sub-directory
from the default user location).

This is not what I am in fact seeing on Sun Java 6u4 for Windows.

 

[Peter Duniho]

[...]

But unfortunately, this filename is not preserved if the user changes
directories in the file chooser. It's reset to an empty state as soon
as one tries to change directories (e.g. descend into a sub-directory
from the default user location).

This is not what I am in fact seeing on Sun Java 6u4 for Windows.

Well, it is what I'm seeing on Apple's Java 1.5 for Mac OS X. I assume
from your reply that you didn't have to do anything special to make it
work nicely. It just does the right thing?

So much for being able to depend on Swing behaving the same regardless of
platform.

Thanks,
Pete

 

[Lew]

[...]

But unfortunately, this filename is not preserved if the user changes
directories in the file chooser. It's reset to an empty state as
soon as one tries to change directories (e.g. descend into a
sub-directory from the default user location).

This is not what I am in fact seeing on Sun Java 6u4 for Windows.

Well, it is what I'm seeing on Apple's Java 1.5 for Mac OS X. I assume
from your reply that you didn't have to do anything special to make it
work nicely. It just does the right thing?

So much for being able to depend on Swing behaving the same regardless
of platform.

So much for Apple being able to provide a correct implementation of Swing.

 

[Sri]

Hi,

I'm developing an application that needs to open a file but I can't
find out how to bring up that normal windows so that I can choose a
file I want to open.

Can anyone help me?

Thanks

Flick
careersengine.com

is it web based or standalone application??. If it is web based
application used the html <INPUT TYPE=FILE NAME="upfile">

 

[Peter Duniho]

So much for Apple being able to provide a correct implementation of
Swing.

Well, there's that too.

But, I was under the impression that one presumed advantage of using Swing
was that it is itself implemented in Java and other than the specific
"look and feel" parts, the same Swing implementation is used for each
run-time. From this issue, I infer that is not the case.

Is Swing implemented in Java? If so, why isn't the exact same
implementation used on each platform (not counting the specific "look and
feel" for specific controls, of course).

Pete

 

[Larry A Barowski]

Well, there's that too.

But, I was under the impression that one presumed advantage of using Swing
was that it is itself implemented in Java and other than the specific
"look and feel" parts, the same Swing implementation is used for each
run-time. From this issue, I infer that is not the case.

Is Swing implemented in Java? If so, why isn't the exact same
implementation used on each platform (not counting the specific "look and
feel" for specific controls, of course).

What L&F are you using on OS X? Does the problem happen
with Metal?

 

[Daniel Pitts]

Well, there's that too.

But, I was under the impression that one presumed advantage of using
Swing was that it is itself implemented in Java and other than the
specific "look and feel" parts, the same Swing implementation is used
for each run-time. From this issue, I infer that is not the case.

Is Swing implemented in Java? If so, why isn't the exact same
implementation used on each platform (not counting the specific "look
and feel" for specific controls, of course).

Pete

Well, the L&F off the JFileChooser is very specific to the OS, including
which "features" it offers. So, from the API point of view, the
JFileChooser returns a set of files. From the user point of view, the
functional appearance depends greatly on the OS, as each OS has a
standard approach to the task.

 

[Peter Duniho]

What L&F are you using on OS X? Does the problem happen
with Metal?

I don't know the answers to either of those questions. When I first
noticed this issue, I briefly tried to see what would be involved in
changing the look-and-feel (partly also because the default appearance of
this chooser is nothing like the built-in Mac OS file chooser). But I
wasn't able to find what I needed quickly enough and it wasn't important
enough to me to pursue it that far.

So I don't actually know how to inspect the current look-and-feel, nor do
I know how to change the dialog to a different look-and-feel. If it's a
simple process, I welcome any specific advice on how to do that, and I'd
be happy to compare the behavior for different configurations. (I'm
actually reasonably good at finding things on my own, but it does
sometimes take awhile and so if the motivation for finding something is
less than compelling, I do just move on to other things in some cases ).

For the time being, I've gone back to the AWT FileDialog. It uses the
built-in chooser and while it's got its own problems, they are relatively
minor compared to this issue with the JFileChooser (the main one being
that FileDialog doesn't offer any way to provide a file filter that the
user can control).

Thanks,
Pete

 

[Peter Duniho]

Well, the L&F off the JFileChooser is very specific to the OS, including
which "features" it offers. So, from the API point of view, the
JFileChooser returns a set of files. From the user point of view, the
functional appearance depends greatly on the OS, as each OS has a
standard approach to the task.

Well, that's what I thought would be the case. But the JFileChooser on
the Mac is definitely _not_ dependent on the OS. It's not using any
existing OS implementation (or at least, not one I've ever seen). In
fact, one strong motivation for me going back to the AWT FileDialog class
is that the JFileChooser is so non-compliant with the Mac OS UI.

How much does the look-and-feel control? I was under the impression that
it was mainly a question of how individual controls looked, and in some
cases operated (i.e. buttons, toggle controls, etc. should all _work_ the
same on any OS, but more complex controls might vary in subtle ways, like
a combo box, list box, etc.). But it's not clear to me whether this
variability can extend all the way up to the entire dialog itself.

Is there some other look-and-feel that I might be able to choose that
would work more like the built-in Mac OS dialog? Or perhaps even just use
it directly?

Thanks,
Pete

 

[Daniel Pitts]

Well, that's what I thought would be the case. But the JFileChooser on
the Mac is definitely _not_ dependent on the OS. It's not using any
existing OS implementation (or at least, not one I've ever seen). In
fact, one strong motivation for me going back to the AWT FileDialog
class is that the JFileChooser is so non-compliant with the Mac OS UI.

How much does the look-and-feel control? I was under the impression
that it was mainly a question of how individual controls looked, and in
some cases operated (i.e. buttons, toggle controls, etc. should all
_work_ the same on any OS, but more complex controls might vary in
subtle ways, like a combo box, list box, etc.). But it's not clear to
me whether this variability can extend all the way up to the entire
dialog itself.

Is there some other look-and-feel that I might be able to choose that
would work more like the built-in Mac OS dialog? Or perhaps even just
use it directly?

Thanks,
Pete

Did you set the system look-and-feel before initializing your Swing
code? That should make it act more like a Mac GUI. I usually call this
in the EDT first thing:
private void initializeSystemLookAndFeel() {
try {

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
} catch (Exception e) {
throw new RuntimeException(e);
}
JFrame.setDefaultLookAndFeelDecorated(true);
JDialog.setDefaultLookAndFeelDecorated(true);
}

 

[Peter Duniho]

Did you set the system look-and-feel before initializing your Swing
code? That should make it act more like a Mac GUI.

I haven't done anything explicitly, no. That said, wouldn't the default
configuration already be set to be the look-and-feel for the OS? Assuming
the user hasn't changed it, of course.

I included the code you posted as part of my initialization, and it
doesn't change how the JFileDialog looks or operates.

I usually call this in the EDT first thing:

"EDT"?

Pete

 

[Daniel Pitts]

I haven't done anything explicitly, no. That said, wouldn't the default
configuration already be set to be the look-and-feel for the OS?
Assuming the user hasn't changed it, of course.

Usually it defaults to the metal look and feel in my experience, not the
"System" look and feel.

I included the code you posted as part of my initialization, and it
doesn't change how the JFileDialog looks or operates.

Does it look anything like the Mac OS file dialog? What happens when
you run your program on Windows?

"EDT"?

Pete

EDT = Event Dispatch Thread (eg, using EventQueue.invokeLater())
Everything that interacts with swing components should do so from that
thread.

 

[Peter Duniho]

Usually it defaults to the metal look and feel in my experience, not the
"System" look and feel.

Well, I'm not that familiar with the different "looks" and "feels", but
while the program defaults to a decidedly non-XP look on Windows XP, on
the Mac the look-and-feel is very much Mac-like. I'd just assumed the
Windows default was supposed to be Vista-like, but I don't really have
enough experience with Vista to know. Maybe it's the "metal"
look-and-feel after all and I just didn't recognize it as such.

It's not surprising that Apple would choose to make their own
look-and-feel the default though.

The funny thing is, though...

Does it look anything like the Mac OS file dialog? What happens when
you run your program on Windows?

No, it looks nothing like the Mac OS file dialog. On Windows,
JFileChooser looks (mostly) the same as Mac if I don't include the code
you suggested, but that version doesn't blow away the filename when you
change directories (i.e. it works fine). If I do include the
initialization code you suggested, then the Swing JFileChooser looks the
same as the AWT FileDialog, which in turn looks the same as the Windows
built-in file chooser dialog.

On the Mac, AWT always looks like the OS dialog, Swing always doesn't,
regardless of whether I include the code you suggested. Interestingly,
the Swing dialog _does_ look a lot like the Windows one, other than the
fact that the various control elements within the dialog still have the
Mac look. But it doesn't behave as well, and it doesn't change depending
on whether the look-and-feel is explicitly set at startup or not.

Which is odd, actually. Given the Windows behavior, it would make more
sense for the "metal" version of the dialog to only show up if I somehow
managed to get the rest of the UI in the "metal" look-and-feel. I assume
there's an explicit class that I could use to do that (the docs appear to
suggest javax.swing.plaf.metal.MetalLookAndFeel). Given that the rest of
the application appears to default to the system look-and-feel on the Mac,
it seems odd that the "metal" dialog is what shows up with JFileChooser.

I am starting (hah ) to think that maybe these issues are all pretty
much related to the same issue: Apple just didn't implement the Java
run-time carefully and failed to be consistent with how the run-time works
on other systems.

EDT = Event Dispatch Thread (eg, using EventQueue.invokeLater())
Everything that interacts with swing components should do so from that
thread.

Never heard of it. I wonder if that means I'm doing something wrong.

I do all of my initialization, including creating the UI, from the thread
that calls the main() method (i.e. all of the initialization, other than
class member initializers, is done in calls from that method). After
that, everything happens in whatever thread handles the UI (i.e. the
program has no additional threads...it only ever does something as a
reaction to some UI event).

I assume that the stuff that happens in the thread that handles the UI is
fine, but is there something wrong with where I'm initializing the UI?
Should I somehow be getting my initialization code to be running on a
different thread than the one that calls my main() method?

Thanks,
Pete

 

[Peter Duniho]

[...] Given that the rest of the application appears to default to the
system look-and-feel on the Mac, it seems odd that the "metal" dialog is
what shows up with JFileChooser.

Ah, posted too soon. The dialog that shows up by default with the
JFileChooser does share the layout with the "metal" dialog, but it's
otherwise a regular Mac dialog. I did try explicitly setting the "metal"
look-and-feel and on the Mac, that produces yet another result: a dialog
that looks much more like the Windows "metal" dialog, and which also works
correctly.

Unfortunately, the "metal" look is much too much out of place on the Mac.
Even on Windows, it's a bit of a stretch, but it just doesn't work at all
on the Mac. I'm afraid I'm back to sticking with the AWT dialog.

Pete

 

[Daniel Pitts]

[...] Given that the rest of the application appears to default to
the system look-and-feel on the Mac, it seems odd that the "metal"
dialog is what shows up with JFileChooser.

Ah, posted too soon. The dialog that shows up by default with the
JFileChooser does share the layout with the "metal" dialog, but it's
otherwise a regular Mac dialog. I did try explicitly setting the
"metal" look-and-feel and on the Mac, that produces yet another result:
a dialog that looks much more like the Windows "metal" dialog, and which
also works correctly.

Unfortunately, the "metal" look is much too much out of place on the
Mac. Even on Windows, it's a bit of a stretch, but it just doesn't work
at all on the Mac. I'm afraid I'm back to sticking with the AWT dialog.

Pete

If you don't know what the EDT is, then you are likely doing something
wrong. I suggest looking at the sun tutorial on Swing and threads.
<http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html>

Actually, I *really* recommend is reading Java Concurrency in Practice.
It really is a must read for most non-trivial Java application developers.
<http://virtualinfinity.net/wordpress/technical-book-recommendations/java-concurrency-in-practice/>

It actually could explain your problems, but it might not. Incorrect
concurrency can cause strange things to happen.

 

[Peter Duniho]

If you don't know what the EDT is, then you are likely doing something
wrong. I suggest looking at the sun tutorial on Swing and threads.
<http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html>

Hmmm. Well, that article seems to say that my code is perfectly fine. It
specifically calls out initialization as something that's okay to do in
the main thread. My code in fact looks a lot like the sample they offer:
a bunch of initialization in the main() method, with the last thing being
a call to show() (in my case, setVisible(true), per the Java docs saying
that show() is deprecated in favor of setVisible(true)).

I'm familiar with the issues relating to using GUI objects on a thread
other than where they are created, having a fair amount of experience
writing to both the Windows and Mac OS API, both of which are very strict
about making sure you create the object on the same thread where the
message pump for the object will be run (for example, on Windows you won't
even get messages for a given window instance except on the thread where
that window was created, so you must always have a message pump on the
thread where the object was created, and the OS will always marshal calls
to the window procedure across to the correct thread).

But my reading of the Java docs I've seen, and the article you've offered,
suggest that in Java, the objects can in fact be created on a different
thread from where their events will actually be processed, and not only
that, that it's a reasonably common technique. The only rule is that once
the object has been shown, it must only be interacted with on the EDT.

Thanks,
Pete

 

[Daniel Pitts]

Hmmm. Well, that article seems to say that my code is perfectly fine.
It specifically calls out initialization as something that's okay to do
in the main thread. My code in fact looks a lot like the sample they
offer: a bunch of initialization in the main() method, with the last
thing being a call to show() (in my case, setVisible(true), per the Java
docs saying that show() is deprecated in favor of setVisible(true)).

I'm familiar with the issues relating to using GUI objects on a thread
other than where they are created, having a fair amount of experience
writing to both the Windows and Mac OS API, both of which are very
strict about making sure you create the object on the same thread where
the message pump for the object will be run (for example, on Windows you
won't even get messages for a given window instance except on the thread
where that window was created, so you must always have a message pump on
the thread where the object was created, and the OS will always marshal
calls to the window procedure across to the correct thread).

But my reading of the Java docs I've seen, and the article you've
offered, suggest that in Java, the objects can in fact be created on a
different thread from where their events will actually be processed, and
not only that, that it's a reasonably common technique. The only rule
is that once the object has been shown, it must only be interacted with
on the EDT.

Ah, I must have linked to an out-dated article. I read that they
believed it was fine to do that, but in reality even initialization
should be done on the EDT.

Thanks,
Pete

The best experiment would be to provide an SSCCE. Something that simply
creates a JFileChooser on the EDT after setting the look-and-feel correctly.