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(); }
Related
we have the following problem:
In our Eclipse RCP 4 application there are multiple parts and the parts are closable. When the user is closing a part there should be a custom pop-up (depending on some internal part state) which is asking the user if he really wants to close the part or not.
It seems to be not that easy to implement in Eclipse RCP 4 or we have just totally overseen something.
I'll just give you a short brieifing about the things we tried:
Use dirtable with a #persist method in the part. Though the problem is, we don't want this standard eclipse save dialog. So is there a way to override this?
public int promptToSaveOnClose(): This seemed to be promising but not for Eclipse 4 or is there a way to integrate it that way? Compare: http://e-rcp.blogspot.de/2007/09/prevent-that-rcp-editor-is-closed.html
Our last try was to integrate a custom part listener, simple example shown in the following:
partService.addPartListener(new IPartListener() {
public void partVisible(MPart part) {
}
public void partHidden(MPart part) {
partService.showPart(part, PartState.ACTIVATE);
}
public void partDeactivated(MPart part) {
}
public void partBroughtToTop(MPart part) {
}
public void partActivated(MPart part) {
}
});
The problem with this was we are running into a continuous loop. Something similar is posted over here in the last comment: Detect tab close in Eclipse editor
So I could write some more about this problem, but I think that's enough for the moment. If you need some more input just give me a hint.
Thanks for helping.
The save prompt is generated by the ISaveHandler registered in the context of the MWindow containing the MPart. You can write your own ISaveHandler and set it in the window context to replace the default.
You might also want to look at the IWindowCloseHandler also in the window context.
Thanks greg, this has helped and I was able to achieve changing the pop-up when the user closes a part. Here's a short description of what I've done:
Use the MDirtyable for marking the part as dirty whenever it's needed.
Create a custom save handler which implements ISaveHandler (when a part got closed the save method is called). Add the additional logic to this handler (e.g. a custom message dialog)
Register this handler at application start-up (I just chose a method which is called at the start-up):
#Inject
private MWindow window;
...
ISaveHandler saveHandler = new CustomSaveHandler(shell);
window.getContext().set(ISaveHandler.class, saveHandler);
Note that the registration via a model processor was sadly not that easy because the model processor is called too early. (Take a look at: http://www.eclipse.org/forums/index.php/t/369989/)
The IWindowCloseHandler is just needed when the complete window is closed, though this was not an requirement for us :).
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 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.
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.
I am trying to write a JTextPane which supports some sort of coloring: as the user is typing the text, I am running some code that colors the text according to a certain algorithm. This works well.
The problem is that the coloring operations is registered with the undo manager (a DefaultDocumentEvent with EventType.CHANGE). So when the user clicks undo the coloring disappears. Only at the second undo request the text itself is rolled back.
(Note that the coloring algorithm is somewhat slow so I cannot color the text as it is being inserted).
If I try to prevent the CHANGE events from reaching the undo manager I get an exception after several undo requests: this is because the document contents are not conforming to what the undoable-edit object expects.
Any ideas?
You could intercept the CHANGE edits and wrap each one in another UndoableEdit whose isSignificant() method returns false, before adding it to the UndoManager. Then each Undo command will undo the most recent INSERT or REMOVE edit, plus every CHANGE edit that occurred since then.
Ultimately, I think you'll find that the styling mechanism provided by JTextPane/StyledDocument/etc. is too limited for this kind of thing. It's slow, it uses too much memory, and it's based on the same Element tree that's used to keep track of the lexical structure of the document. It's okay (I guess) for applications in which the styles are applied by the user, like word processors, but not for a syntax highlighter that has to update the styles constantly as the user types.
There are several examples out there of syntax-highlighting editors based on custom implementations of the Swing JTextComponent, View and Document classes. Some, like JEdit, re-implement practically the whole javax.swing.text package, but I don't think you need to go that far.
How are you trying to prevent the CHANGE events from reaching the undo manager?
Can you not send the UndoManager a lastEdit().die() call immediately after the CHANGE is queued?
I can only assume how you are doing the text colouring. If you are doing it in the StyledDocuments change character attribute method you can get the undo listener and temporarily deregister it from the document for that operation and then once the colour change has finshed then you can reregister the listener.
Should be fine for what you are trying to do there.
hope that helps
I have just been through this problem. Here is my solution:
private class UndoManagerFix extends UndoManager {
private static final long serialVersionUID = 5335352180435980549L;
#Override
public synchronized void undo() throws CannotUndoException {
do {
UndoableEdit edit = editToBeUndone();
if (edit instanceof AbstractDocument.DefaultDocumentEvent) {
AbstractDocument.DefaultDocumentEvent event = (AbstractDocument.DefaultDocumentEvent) edit;
if (event.getType() == EventType.CHANGE) {
super.undo();
continue;
}
}
break;
} while (true);
super.undo();
}
#Override
public synchronized void redo() throws CannotRedoException {
super.redo();
int caretPosition = getCaretPosition();
do {
UndoableEdit edit = editToBeRedone();
if (edit instanceof AbstractDocument.DefaultDocumentEvent) {
AbstractDocument.DefaultDocumentEvent event = (AbstractDocument.DefaultDocumentEvent) edit;
if (event.getType() == EventType.CHANGE) {
super.redo();
continue;
}
}
break;
} while (true);
setCaretPosition(caretPosition);
}
}
It is an inner class in my custom JTextPane, so I can fix the caret position on redo.