I would like to use a JTable for editing a JTree, I extended DefaultTreeCellEditor and implemented isCellEditable getTreeCellEditorComponent, in getTreeCellEditorComponent I return a JTable. Everything works up to this point when a node is edited swing displays the JTable filled with the objects content however when editing is complete, valueForPathChanged of DefaultTreeModel never gets called. If I use a text field for editing which is the default everything works fine.
JTextField has a notifyAction, named "notify-field-accept" and typically bound to KeyEvent.VK_ENTER, that signals the CellEditor to stopEditing() and ultimately invokes the DefaultTreeCellEditor method, valueForPathChanged().
It's not clear how you indicate that editing is complete for your JTable. You should be able to do something similar with the JTextField in a CellEditorListener that is added to your custom editor via addCellEditorListener().
Incidentally, valueForPathChanged() mentions that "If you use custom user objects in the TreeModel you're going to need to subclass this and set the user object of the changed node to something meaningful."
Related
I have a Swing application that shows a list of complex objects to the user. These are nicely rendered using a ListCellRender, which fills a JPanel with more UI controls. Obviously editing does not work and the components are not enabled to accept input.
Now I want the user to be able to edit the entries. Basically you could think of in-place editing. I tried to simply enable the panel that renders the list entries - but it does not work. What else could/should I do to have an editable list?
So basically the answer is to favour JTable over JList. For anyone questioning that, the JTable can be configured to show one column only, and the difference would not be visible to the user.
Programming wise JTable is more complex and thus justifies that JList is used in simple cases (only one columne, no editing required).
Often when using JTable or JTree, user define its own cell renderer.
It is very common to inherit user's component from DefaultTableCellRenderer, and implements the renderer method getTableCellRendererComponent. It turns out that DefaultTableCellRenderer in fact inherits from JLabel, thus returns itself (this) when called to super (at the render method) and thus user's renderer can similarly returns itself (this) as well.
And it all works well.
My question is how can it be?
Each time this method is called by the table, it is given different parameters, and the output label is changed as function of these parameters. If it is indeed the same instance of the label – shouldn't it be changed according to the last call to this method?
Wouldn't it mean that all of the table's cells are infect composed of the same label instance, which holds the same value (value of last call to the renderer method)?
I have searched the web, and dig within Swing's code, and could not find any act of clone or copy constructor that actually duplicates the output label.
I could not find any evidence that (perhaps) swing uses reflection in order to re-instantiate the renderer each time from scratch.
I have read the Swing's tutorial on JTables, and there I could find the next lines:
You might expect each cell in a table to be a component. However, for performance reasons, Swing tables are implemented differently.
Instead, a single cell renderer is generally used to draw all of the cells that contain the same type of data. You can think of the renderer as a configurable ink stamp that the table uses to stamp appropriately formatted data onto each cell. When the user starts to edit a cell's data, a cell editor takes over the cell, controlling the cell's editing behavior.
They give a hint, that indeed what I am saying is correct, but do not explain how its actually being accomplished.
I can't get it. Can any of you?
It's an implementation of the flyweight pattern.
When the JTable repaints itself, it starts a loop and iterates over every cell that must be painted.
For each cell, it invokes the renderer with the arguments corresponding to the cell. The renderer returns a component. This component is painted in the rectangle corresponding to the current table cell.
Then the renderer is called for the next cell, and the returned component (which has a different text and color, for example), is painted in the rectangle corresponding to the cell, etc.
Imagine that each time the renderer is called, a screenshot of the returned component is taken and pasted into the table cell.
In adition to #JB's clear explication of how JTable and JTree use the flyweight pattern, note how both classes provide public methods getCellRenderer() and getCellEditor(). Examine these methods to see how JTable uses Class Literals as Runtime-Type Tokens to select a renderer or editor by class, if none is specified by column. Internally, JTable uses a Hashtable defaultRenderersByColumnClass for instance storage.
After some digging, found the next implementation note from DefaultTableCellRenderer documentation:
Implementation Note: This class inherits from JLabel, a standard component class. However JTable employs a unique mechanism for rendering its cells and therefore requires some slightly modified behavior from its cell renderer. The table class defines a single cell renderer and uses it as a as a rubber-stamp for rendering all cells in the table; it renders the first cell, changes the contents of that cell renderer, shifts the origin to the new location, re-draws it, and so on. The standard JLabel component was not designed to be used this way and we want to avoid triggering a revalidate each time the cell is drawn. This would greatly decrease performance because the revalidate message would be passed up the hierarchy of the container to determine whether any other components would be affected. As the renderer is only parented for the lifetime of a painting operation we similarly want to avoid the overhead associated with walking the hierarchy for painting operations. So this class overrides the validate, invalidate, revalidate, repaint, and firePropertyChange methods to be no-ops and override the isOpaque method solely to improve performance. If you write your own renderer, please keep this performance consideration in mind.
This is essentially what JB explained above.
Thanks for the (quick) answers
We currently have a focus problem with a JTable/JTextEditor in java swing. The JTable has a custom cell editor which is a JTextField.
The issue is when a cell is being edited and contains invalid data, and the user clicks on a JButton, the text field will stop editing and the JButton actionPerformed (clicked) is called. The JTable#setValueAt handles validation so if the data in the JTextField is invalid, the underlying TableModel is not updated.
Ideally, we do not want to let the JButton click occur. Focus should remain with the JTable or the JTextField.
Clicking the button will perform a submit action and close the frame the table is in. As the validation in the TableModel#setValueAt does not update the value, it submits the old value.
Can this be done? I am still fairly new to Swing so I am not aware what to check.
Unfortunately, our code is not straight forward. The UI is constructed from XML in such a way that the button knows nothing about anything else on a form (this is code I have inherited).
In .net you could stop a control losing focus by handling a Validating event and setting a cancel flag. Is there a similar mechanism with Java.
Validating the input after editing has concluded, in setValueAt(), may be inconveniently late. The editor itself can preclude navigation for invalid values, as shown in this example that links to the corresponding tutorial section.
For valid values, you can make the table commit when losing focus:
table.putClientProperty("terminateEditOnFocusLost", true);
Can you try using inputverifier on the editor component, i.e. text field?
When the focus is lost from a component, the lost focus method is called (more reference in http://docs.oracle.com/javase/tutorial/uiswing/events/focuslistener.html). Therefore, you may call the validation method when you lose the focus.
If you do not need to be aware of the specific field being edited, you can also perform validation inside your button and prevent the submission if it is not sucessful.
I'd achieved a similar functionality by overriding the stopCellEditing method in my JTable's CellEditor.
#Override
public boolean stopCellEditing() {
String s = (String) getCellEditorValue();
if (s != null) {
if (!testYourValue()) {
Toolkit.getDefaultToolkit().beep();
return false;
}
}
return super.stopCellEditing();
}
I've got a JTree with a custom TreeModel and a custom TreeCellEditor displaying (for now) a JComboBox through the getTreeCellEditorComponent() override. The tree is displayed properly, with the nodes going into edit mode and displaying the JComboBox when I click on them.
Whenever I edit a node, changing the value from the dropdown, and then proceed to select another node from the three, I can see the TreeCellEditor's cancelCellEditing() being triggered.
What's the "correct" way to stop editing in stead of cancelling it, thus (hopefully?) making sure the model's valueForPathChanged() get's triggered?
After further investigation in the source code I found the answer inside the JTree class:
Setting JTree#setInvokesStopCellEditing(true) means editing is stopped in stead of cancelled whenever I change focus from one node to another. This also means my TreeModel#valueForPathChanged() gets called.
I've got a JTree which I'm using to display some (unsurprisingly) hierarchical data. Part of the spec is that the user can change the data source (atm it's just between files). Now, when this happens, I can rebuild the data and the tree nodes with no problem. But, I'm having substantial difficulties getting the tree to update the changes. I tried removing it from it's scrollpane and replacing with a new JTree, but I didn't see any such. I've tried removing all from the JTree and didn't see any effect.
How can I make the JTree display changes after it's been constructed?
Ninjedit: Yes, I did call updateUI().
Another edit:
I also wanted to replace the tree's current data with my new data. However, I don't see any methods that will take the DefaultMutableTreeNode that I constructed with. Even if I just remove the JTree and call updateUI on it's containing ScrollPane, nothing happens. Or if I use repaint instead.
It could be that the proper events (the JTree internal events) are not being fired. For example, you can add nodes either by using node.add(...) or even better, model.insertNodeInto(...) (assuming you're using the DefaultTreeModel). In this case, the latter method is preferred as it will fire appropriate events that will cause the view (the JTree) to update correctly. It's possible that your problem isn't with redrawing the UI, but in fact notifying the view that the model has changed.
So, I would suggest looking in to how you're dynamically modifying your JTree, and if possible I'd suggest using the DefaultTreeModel as your model to drive the view.
And just to make sure, you've read through the Sun JTree tutorials, right?