I ran into an issue with JFileChooser and wanted to see if there is a workaround.
If the JFileChooser is created and the setFileSelectionMode is FILES_AND_DIRECTORIES, when a user clicks a shortcut button on the left (in XP) such as Desktop or My Documents or drop down to Desktop, the field is not placed in the File Name JTextPane. And when clicking the "Select/Accept" button, nothing happens (because isDirectorySelected() returns false for some reason).
Overriding the approveSeletion does not work because the Event Handler function in BasicFileChooser does not call it.
How would I make it so the Desktop can be selected without having to navigate to it manually, but by clicking the shortcut on the left?
Thanks
In Windows, the desktop is not backed by any file in the file system - it's a shell namespace. So there really isn't anything that JFileChooser could return to you. Yes, I know that there is a folder that contains the desktop for the user - but remember that the desktop actually displays as a composite of the user's desktop and the All Users desktop folder - plus other things that are added by the shell but not part of any folder (like the trash bin). So returning a File object that represents the 'desktop' is pretty much a non-starter.
Long and short: Ask yourself why you need to do this - chances are that you are going to wind up deep into native code territory, dealing with namespace PIDLs and all sorts of nastiness that you may not want to get into (for the life of me, I cannot understand why M$ had to make this stuff so amazingly difficult to use)...
Here's an intro to Windows shell namespaces so you'll have a feel for what's involved:
http://msdn.microsoft.com/en-us/library/cc144090%28v=vs.85%29.aspx
Found the following code in the BasicFileChooserUI:
if (fc.getFileSelectionMode() == JFileChooser.FILES_AND_DIRECTORIES
&& fc.getFileSystemView().isFileSystem(dir)) {
setFileName(dir.getAbsolutePath());
}
So it looks like "special folders" are purposely ignored. The code is in a private method so it would be hard to create you own UI.
As a hack you might be able to add a PropertyChangeListener to the file chooser:
public void propertyChange(final PropertyChangeEvent e)
{
String prop = e.getPropertyName();
if (JFileChooser.DIRECTORY_CHANGED_PROPERTY.equals(prop))
{
JFileChooser fileChooser = (JFileChooser)e.getSource();
File currentDirectory = (File)e.getNewValue();
String directory = currentDirectory.toString();
if (directory.endsWith("Desktop")
|| directory.endsWith("My Documents"))
{
File selectedFile = fileChooser.getSelectedFile();
if (selectedFile == null || ! selectedFile.equals(currentDirectory))
{
fileChooser.removePropertyChangeListener( this );
fileChooser.setSelectedFile( currentDirectory );
fileChooser.addPropertyChangeListener( this );
}
}
}
}
Related
I am using JavaFX to write a script, part of which involves the user selecting an existing project, or creating a new one. In the latter case I have a popup window that prompts the user for a name and a place to save the project. What I hope to do is create a folder in the place that the user specifies with the same name as the project, from here I will save different items to it and load them later. However when I use filechooser to have the user pick the location for the folder it requires them to select an item before the chooser actually picks anything. Then the folder that it makes has the name of this item in the beginning. (For example if I picked the Chrome shortcut on my desktop the folder name would be chrome.exeProject1 or something like that)
I know part of the problem is because I reused part of my filechooser code for a different function where I required the user to have an item selected before they could submit it, anyway...
Is there any way for the user to select a folder, or just submit the filechooser without selecting any items and create the new folder here? (Inside the selected folder or in the current folder in the latter case).
relevant code below, any help is appreciated. Thanks!
#FXML
private void submitName(ActionEvent event) {
name = nameOfProject.getText();
if (name != null && location != null)
{
new File(location + name).mkdir();
}
}
#FXML
private void createProjectDirectory(ActionEvent event) {
FileChooser projectDirectory = new FileChooser();
projectDirectory.setTitle("Create Project Directory:");
File refLocation = projectDirectory.showOpenDialog(null);
if (refLocation != null) {
locationOfProject.clear();
location = refLocation.getPath();
locationOfProject.appendText(location);
}
}
You have to use DirectoryChooser instead of FileChooser to let the user select a directory.
You can read the documentation on how to use these classes here (it's from JavaFX 2, but I guess the interface is mostly the same).
I want to know which file (or even project is enough) is opened in eclipse editor? I know we can do this once we get IEditorPart from doSetInput method,
IFile file = ((IFileEditorInput) iEditorPart).getFile();
But I want the name of file without using IEditorPart, how can I do the same?
Checking which is the selected file in project explorer is not of much help because, user can select multiple files at once and open all simultaneously and I did not way to distinguish which file opened at what time.
Adding more info:
I have an editor specified for a particular type of file, now every time it opens, during intializing editor I have some operation to do based on project properties.
While initializing editor, I need the file handle (of the one which user opened/double clicked) or the corresponding project handle.
I have my editor something this way:
public class MyEditor extends TextEditor{
#Override
protected void initializeEditor() {
setSourceViewerConfiguration(new MySourceViewerConfiguration(
CDTUITools.getColorManager(), store,
"MyPartitions", this));
}
//other required methods
#Override
protected void doSetInput(IEditorInput input) throws CoreException {
if(input instanceof IFileEditorInput)
{
IFile file = ((IFileEditorInput) input).getFile();
}
}
}
as I have done in the doSetInput() method , I want the file handle(even project handle is sufficient). But the problem is in initializeEditor() function there is no reference to editorInput, hence I am unable to get the file handle.
In the source viewer configuration file, I set the code scanners and this needs some project specific information that will set the corresponding rules.
You never have the guarantee (even with IFileEditorInput) to know which files are "open" with editors.
There is even no definition of an "opened file" there are for example editors that show the contents of multiple files (like the Plug-In Manifest Editor from PDE). Other editors show only the contents of a URI (which maybe local)
Could you explain which problem you are trying to solve?
I was wondering if there is a GUI file explorer package in java to save me some time.
I'm talking about anything like the window you would see when "Browsing" a file in windows for loading into a media player for example.
Something like this:
Please I am asking if a specific package or methods exist to accommodate this. Just saying Jframe and swing is not really what I am looking for.
You are looking for http://docs.oracle.com/javase/tutorial/uiswing/components/filechooser.html
JFileChooser chooser = new JFileChooser();
int option = chooser.showOpenDialog(SimpleFileChooser.this);
if (option == JFileChooser.APPROVE_OPTION) {
statusbar.setText("You opened " + ((chooser.getSelectedFile()!=null) ? chooser.getSelectedFile().getName():"nothing"));
}
else {
statusbar.setText("You canceled.");
}
I searched in Google for something like this however I must not have phrased it correctly.
We have java.awt.FileDialog that uses the native file system explorer(more user friendly) and like fvu said JFileChooser. A tutorial for http://www.tutorialspoint.com/awt/awt_filedialog.htm here.
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.