I am using JFileChooser as part of an export feature. I would like for the user to be able to either select a file from JFileChooser's file viewer or enter the name of a file in the filename text box. From what I've read it's possible to get that value using the getSelectedFile() method, so I have some listeners that call getSelectedFile() and attempt to do some checks before executing the export.
The problem I'm encountering is that the getSelectedFile() method is returning null when I enter the name into the filename text box manually. To add more confusion, the getSelectedFile() method does work in three different situations:
I populate it via setSelectedFile() (a user has clicked a value from a table and I use setSelectedFile())
I click an existing file in the file viewer
I hit ENTER after populating the filename text box
I have three file filters but have had the same behavior regardless of if they are enabled or not.
Listeners that call getSelectedFile() are as follows:
Event Listener for keyReleased
Event Listener for mousePressed.
PropertyChangeEvent listener on my jFileChooser
Action Listener on my jFileChooser
Is there a better way to listen to my jFileChooser to get the user input? I feel like I'm missing something very obvious ... any help is appreciated!
edit
A little more info ...
I have a JFileChooser component in a JSplitPane, which is in a JFrame. I'm not calling showOpenDialog to get input from the user. The component is accessible as part of the form.
What I would like to do is listen to the user input as he/she types. I have a 'start export' button that I would like to leave disabled until the user has entered a valid filename in the filename textbox in the JFileChooser component. To accomplish this I have a KeyEvent listener that I would like to use to get the filename as the user types it in.
further edit
Here is the action listener code:
jFileChooserExport.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jFileChooserExportActionPerformed(evt);
}
});
I also have a property change listener here:
jFileChooserExport.addPropertyChangeListener(new java.beans.PropertyChangeListener() {
public void propertyChange(java.beans.PropertyChangeEvent evt) {
jFileChooserExportPropertyChange(evt);
}
});
Inside of both jFileChooserExportPropertyChange and jFileChooserExportActionPerformed I am trying to get the file the user has selected by invoking getSelectedFile(). In both cases, however, it remains null until the user does one of the three methods described above
Read the section from the Swing tutorial on How to Use File Choosers. The demo code there works fine for me.
Since none of below seems to work, you might want to try to add a PropertyChangeListener to your JFileChooser, listening for the SELECTED_FILE_CHANGED_PROPERTY
What might be possibly happening is that your file chooser may have multi selection enabled, in which case getSelectedFile will return null, but getSelectedFiles will return an array containing the selected file(s). You may either want to disable multi selection, or use the array (If you want the user to only select one file, set multiSelectionEnabled to false).
Another possibility, though, is if you try to get the selected file but fileChooser.showOpenDialog or fileChooser.showSaveDialog were neither called yet or did not return JFileChooser.APPROVE_OPTION
Also, I believe JFileChooser is case-sensitive, so if the file name is "Foo.bar" and you enter "FoO.bar", it will think you want something else.
Related
I'm currently on NetBeans lessons on how to create Java programs with GUI. I've noticed in several GUI controls the text field and the combobox, the "Action" and the "Name" properties are always present. What is the purpose of these properties and how can I use them? For example, I'll use a text field here:
JTextField aTextField = new JTextField();
String act = "aksyon";
JTextField.setActionCommand(act);
What is the difference of setActionCommand() from setAction()? I thank you in advance for your help.
ActionCommand is the key used to determine the command String for the ActionEvent that will be created when an Action is going to be notified as the result of residing in a Keymap associated with a JComponent.
public void setActionCommand(String command)
Sets the command name for the action event fired by this button. By default this action command is set to match the label of the button.
read more here
I am using the NetBeans GUI Builder to create a small application. To begin, let me just say that I can code everything by hand and solve this problem right away. However, I want to learn how to use the GUI Builder. This is my warning that all suggestions to not use it will get a down vote.
With that said, my current situation is that I have several JFormattedTextFields where I want to display an error message if the user enters data with an invalid format. The logic is the same in every case. The only difference will be to display a different error message depending on the exact formatting expected (i.e. a four digit year, a positive integer, etc.). I would like to simply write one listener that can be reused for every text field. I wrote the following method for the first text box:
private void formattedTextFieldFocustLost(java.awt.event.FocusEvent evt) {
JFormattedTextField source = (JFormattedTextField)evt.getComponent();
if (!source.isEditValid()) {
// TODO: Need a better error message.
JOptionPane.showMessageDialog(this, "Invalid input.", "Input Error", JOptionPane.ERROR_MESSAGE);
source.requestFocusInWindow();
}
}
The method signature is generated by NetBeans and is called from a generated of an anonymous inner class which extends FocusAdapter. Now when I go to the Design view in NetBeans and click on the combo box for the focusLost event of another component, this method name doesn't show up.
I also tried to create a named inner class which extends FocusAdapter. This doesn't show up in the event handler comboboxes, either.
What do I do to create a single method for all of my text fields?
If you have written the handler already, say btnActionPerformed, copy the name.
In design view, right-click the component where you want to attach the handler > Properties > Events > "..." button > Add > paste existing handler name in blank field and click OK.
(Netbeans 7.3.1)
Create your own method, e.g. validate():
private void validate(JFormattedTextField source) {
if (!source.isEditValid()) {
// TODO: Need a better error message.
JOptionPane.showMessageDialog(this, "Invalid input.", "Input Error", JOptionPane.ERROR_MESSAGE);
source.requestFocusInWindow();
}
}
then call this method from the individual listeners that you define through the GUI Editor:
private void formattedTextFieldFocustLost(java.awt.event.FocusEvent evt) {
JFormattedTextField source = (JFormattedTextField)evt.getComponent();
validate(source);
}
I would like to bind a method to my com.icesoft.faces.component.inputfile.InputFile object to get it behave as if was defined so:
<ice:inputFile id="inputFileComponent" actionListener="#{mainWindowManager.uploadActionListener}"
I create the InputFile instance but see several methods and none of them works.. :-(
com.icesoft.faces.component.inputfile.InputFile inputFile = new InputFile();
inputFile.addActionListener(..);
inputFile.setActionListener(..);
inputFile.setActionExpression(..);
inputFile.setAction(..);
Which method is for the binding described in the XML above..?
The method triggered when selecting the file on disk should have this signature :
public void uploadActionListener(ActionEvent e){}
However, there is an additional parameter for ice:inputFile named "autoUpload". When set to true, the file submit should be performed immediately when file is selected on disk (if that is what you want to do).
Here is what it looks like in one of my project :
<ice:inputFile autoUpload="true" actionListener="#{myBean.myMethod}" submitOnUpload="postUpload" immediate="true" />
When the user select the file, the action is triggered immediately and form is submitted. Hope it helps.
The winner is setActionListener(..) but the thing that I missed was setting an ID for the component, this caused all the mess.
Greetings to Swing Pros, here's a good (I hope) question for you.
The below are the task requirements and possible solutions I see. I would like someone having had such a hardcore experience to share some thoughts about this.
This does not require coding or anything like that, I just need general advice as to which approach is more reliable regarding the fact I need to work with private symbols which reside in sun.swing and/or javax.swing.plaf packages.
The task is to modify/alter JFileChooser behaviour (just a little bit, actually).
when the user presses enter in the file name JTextField, and the field contains a path to a dir, don't "select" the dir, but switch to it instead. Yes, the dialog is configured to accept directories, but we need to accept only clicks on the "Open" button, and (possibly) double-clicks in the file listing table.
prevent user from selecting a dir/file with more than 1GB data via hitting enter in the file name text field
Here're couple of general solution options:
a. listen on the property-based changes that JFileChooser provides (which AFAICS are triggered after-the-fact and won't provide the degree of control we need here).
b. tinker with the javax.swing.plaf.basic.BasicFileChooserUI (via refrection, breaking the private-level encapsulation) and alter the reference to
private Action approveSelectionAction = new ApproveSelectionAction();
so that our custom action does the extra checks for 1 and 2. This approach links with plaf package and may fail in case this action is somehow overridden in some class below this UI class.
c. traverse the JFileChooser component hierarchy, find the JTextField (which apparently should occur only once in the component tree), decorate all the action listeners hanging on that JTextField with our custom checks. My debugging session shows that this JTextField is some anonymous subclass of JTextField living in the sun.swing.FilePane.
This approach seems to be more OO-friendly, but there's a chance that for some OS this text field is absent, or some other JTextField is also present in the hierarchy.
Well, it seems that public JFileChooser API would not suffice to achieve that behaviour, while the other two options are either deep magic or unportable (long-term), or even both.
So, the question is: which approach would you choose and why?
Regarding option2, you don't need to use reflection to customize the accept Action. You can just override the approveSelection() method. Something like:
JFileChooser chooser = new JFileChooser( new File(".") )
{
public void approveSelection()
{
if (getSelectedFile().exists())
{
System.out.println("duplicate");
return;
}
else
super.approveSelection();
}
};
I recently encountered the same requirement, i.e., pressing Enter in the JTextField of a JFileChooser should cause the displayed dialog to traverse a directory instead of returning from the dialog. Only clicking on the Open button should cause the final selection.
The solution was fairly simple (at least for my application) and has two components to it (Pardon the messed up formatting. I'm new to this forum and I'm not sure why the code is not displaying correctly).
1 - Register an AWTListener to keep track of the last event type generated by the user
class MyChooser extends JFileChooser implements java.awt.AWTEventListener {
...
MyChooser(){
Toolkit.getDefaultToolkit().addAWTEventListener(this,
AWTEvent.MOUSE_EVENT_MASK + AWTEvent.KEY_EVENT_MASK);
...
}
int lastEventId;
public void eventDispatched(AWTEvent e) {
lastEventId=e.getID();
}
}
2 - Override the approveSelection() method of JFileChooser and check whether the approval request is a result of a mouse event (likely caused by the user clicking on the Open button) or a key event caused by the user pressing Enter. The 'lastEventId' variable provides access to this information. My own approveSelection then looks as follows:
public void approveSelection() {
File f=getSelectedFile();
if (f.exists() && isTraversable(f) && lastEventId ==
KeyEvent.KEY_PRESSED) {
setCurrentDirectory(f);
return;
}
super.approveSelection(); }
How do I change the JFileChooser behavior from double-click selection to single-click selection mode?
I'm developing an application to run with either a single-click interface (nothing requires a double-click, just like the KDE interface mode) or a double-click interface (the default Windows interface mode or the regular GNOME interface mode). I want the Java application to behave just like the rest of the system to respect the user current configuration and environment.
The ideal solution should be to set up a configuration value somewhere in the JFileChooser class to have it work either under single-click ordouble-click mode.
Since it seems there is no such a configuration, here is an approximate solution based on Richie_W's idea. I had to extend it a bit in order to allow the user to navigate in many directories and also to avoid reentrant events that get fired when setting the selection. However, as Oscar pointed out, it is not possible to navigate using the keyboard (it always chooses whatever is under focus). If you don't use the keyboard, it works.
JFileChooser _fileChooser=new JFileChooser();
if (ConfigurationManager.isSingleClickDesired()) {
//We will be interested in files only, but we need to allow it to choose both
_fileChooser.setFileSelectionMode(JFileChooser.FILES_AND_DIRECTORIES);
_fileChooser.addPropertyChangeListener(new PropertyChangeListener() {
//To prevent reentry
private boolean handlingEvent=false;
public void propertyChange(PropertyChangeEvent e) {
//Prevent reentry
if (handlingEvent)
return;
else
//Mark it as handling the event
handlingEvent=true;
String propertyName = e.getPropertyName();
//We are interested in both event types
if(propertyName.equals(JFileChooser.SELECTED_FILE_CHANGED_PROPERTY) ||
propertyName.equals(JFileChooser.DIRECTORY_CHANGED_PROPERTY)){
File selectedFile = (File) e.getNewValue();
if (selectedFile!=null) {
if (selectedFile.isDirectory()) {
//Allow the user to navigate directories with single click
_fileChooser.setCurrentDirectory(selectedFile);
} else {
_fileChooser.setSelectedFile(selectedFile);
if (_fileChooser.getSelectedFile()!=null)
//Accept it
_fileChooser.approveSelection();
}
}
}
//Allow new events to be processed now
handlingEvent=false;
}
});
}
Ps->Sorry for not great looking code format, but StackoverFlow has broken Firefox and Iceweasel code format support under KDE and Gnome.