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
Related
As the title says I'm trying to make it so my JTextArea have some strings so that I can call other functions, like a hyperlink of sorts, can that be done?
For reference, I would like to know how the left side of any Tutorialspoint tutorial is made but in Java.
PS: I'm using a CardLayout.
EDIT: Something like this
Forget about using a JTextArea. Take a look at JList instead. This is Swing's basic list class. It supports the selection of one or more items from a list. Although often the list consists of strings, it is possible to create a list of just about any object that can be displayed.
Although a JList will work properly by itself, most of the time you will wrap a JList inside a JScrollPane, so long lists will automatically be scrollable.
A JList generates a ListSelectionEvent when the user makes or changes a selection. This event is also generated when the user deselects a n item. It is handled by implementing ListSelectionListener. This listener specifies only one method, which is called:
void valueChanged(ListSelectionEvent le)
Here, le is a reference to the object that generated the event. Although ListSelectionEvent does provide some methods of its own, often you will interrogate the JList object itself to determine what has occurred.
By default, a JList allows the user to select multiple ranges of items within the list, but you can change this behavior by calling setSelectionMode(int), which is defined by JList. The integer passed to this method must be one of the values defined by the ListSelectionModel interface:
SINGLE_SELECTION
SINGLE_INTERVAL_SELECTION
MULTIPLE_INTERVAL_SELECTION
You can obtain the selected values by calling getSelectedValuesList(), or, if you are using single selection, you can call getSelectedValue(). Once you have the selected the value(s), you can invoke the method(s) dedicated to that/those objects accordingly.
One last tip: In Java, they are called methods, not functions ;)
Happy programming!
I'm using a JList to hold chat data for my chat program.
It uses a custom list renderer to render a custom JPanel object as the element type.
This JPanel contains two JLabels (anchored to the top, for name and time), and a JTextArea (anchored to the bottom, for chat message).
It looks like this:
Everything works great, but I want to add a hide/show feature.
Using a previously programmed PopupMenu handler, I have a popup appear when you right click on an element.
When you click hide (or show, it's a toggle) then it should minimize the element like so...
The only problem is... it doesn't update the JList cell size as you can see the large empty region where the text used to be.
However, when I type another message...
The JList fixes the cell size completing the 'hide' operation.
My question is how do you get the JList to revalidate/repaint/etc programmatically.
And don't think I haven't tried all the obvious solutions...
public void setHidden(boolean hidden) {
// this is in the custom JPanel class
System.out.println("Initial: " + this.getPreferredSize());
// TextArea is the JTextArea which we set invisible when we want to hide it.
TextArea.setVisible(!hidden); // TextArea is a variable btw
this.invalidate();
this.validate();
this.repaint();
System.out.println("After: " + this.getPreferredSize());
container.revalidate();
}
/*
* This is what the above printlns show when you hide, then show the element.
*
* Initial: java.awt.Dimension[width=176,height=38]
* After: java.awt.Dimension[width=176,height=20]
* Initial: java.awt.Dimension[width=176,height=20]
* After: java.awt.Dimension[width=176,height=38]
*/
public void revalidate() {
// container.revalidate() ^^^
// list is the list containing the chat elements
list.invalidate();
list.validate();
list.repaint();
}
The custom JPanel class uses a GroupLayout to render the components.
Do you guys have any knowledge on how to programmically cause a JList to revalidate its cell sizes?
... besides the methods that I've posted? :)
Solution:
After searching method after method and testing if they would solve my problem, I found that executing this code after a hide/show operation would cause the cell height (and width) to be recalculated and without any unwanted visual 'flicker' of the JList.
list.setFixedCellHeight(0);
list.setFixedCellWidth(0);
list.setFixedCellHeight(-1);
list.setFixedCellWidth(-1);
Without seeing any code, I can only guess: the most probable reason is that you're doing the hide under the feet of the list, that is without its model notifying its listeners. The list's ui delegate caches the cell size deep inside, which is cleared on receiving ListEvents
This is job for JTable with two Columns (Chat and Boolean) in the TableModel and with visible Chat Column only, the trick is by using by implement RowFilter where you set as parameter to the second column only String "false" (Object in the JTable with Boolean is possible filtering with returns value in the String "true" / "false")
This is a very peculiar shortcoming of the JList class. I ran into the issue myself in the course of cleaning up some of my code in unrelated areas.
For what it's worth, removing the element from the ListModel and then adding it again will produce the appropriate dimensions for the associated rendered component in the JList. It's an odd way to go about it, and seems to cause the list to behave the same way as the accepted (and preferred) solution:
list.setFixedCellHeight(0);
list.setFixedCellWidth(0);
list.setFixedCellHeight(-1);
list.setFixedCellWidth(-1);
I stumbled upon this problem because the code for my project was originally written to invoke the removeAllElements() method of the ListModel and then add all of the elements again one by one using addElement(). Everything was working great until I decided that I should rewrite the program so that it would simply leave the model alone whenever changes to the dimensions of the displayed components in the JList were requested by the user. In other words, it was unnecessary to involve the model because elements were not being added or removed from the list. Unfortunately, after changing the preferred size of the renderer, no amount of repaint() or revalidate() method calls on the JList would cause it to layout its elements correctly. In my case, only resizing the parent component (a JFrame) produced the intended behavior.
Summary
What is the renderer class for UIXIterator(af:iterator)?
Background
I am writing a component and I am planning to extend UIXIterator just like UIXTable does. My component will basically accept the same kind of data binding as UIXIterator/UIXTable does. The only difference will be in the rendering and the client behavior.
I am conducting some preliminary checks to see if this is feasible and how I will go about doing this. I have already determined that most likely I can just extend the component and tag classes(UIXIterator and UIXIteratorTag respectively). The only thing that I am not able to find is the renderer class for UIXIterator.
There is no default Renderer. It renders himself, unless you did not set rendererType in UIXIterator class.
I have extended the AbstractTableModel to suit my requirements. Now this table can be altered by other methods of my GUI. I want the table to scroll to the currently edited cell into view. To do this, I think I have to first get the JViewport of the current JComponent, but I see no method by which I can achieve this? How do I achieve this?
I have already done this when I have used the default JTable, but how do I do this when we extend AbstractTableModel?
Models are designed to store data and notify views when the data has changed. It notifies the view of a change in data by firing events. It is the responsibility of the view to listen for these events. Therefore the model never knows directly what view is being updated. This type of functionality should NOT be part of the model.
One approach might be to use a TableModelListener. You can create a TableModelListner with the table as a paramenter. Then when data is changed the listener will be notified. You can then invoke table.scrollRectToVisible(...) on the table. However, with this approach you can't distinquish between edits that have been applied directly through the TableModel versus udates that have been done through the JTable itself.
You may want to have your table fire an event, and have your parent component listen for that event, and scroll accordingly. That way your table doesn't need to know about its parent scroll pane.
You can make use of the EventListenerList in DefaultTableModel to notify any listeners.
I have been looking into JTree and TreeCellRenderer. It seems in general, the application (with one JTree) has only one instance of TreeCellRenderer. The application makes multiple calls to TreeCellRenderer's getTreeCellRendererComponent method to decide how each TreeCell is drawn, and such call are made in many occasions (when a cell is selected, deselected, move over, when scrolling, etc.). Why did they decide to do that instead of having multiple instances of TreeCellRenderer, each responsible for one cell??
I am trying to make a JTree where each cell contains a checkbox. The checkbox can be checked/unchecked by the user. Then, the TreeNode userObject's values are set base on the state of these checkboxes. But, from the current JTree design this is impossible - since there is only one instance of JCheckBox, and is only used to show how the Cell looks like (you can't really check it). In some sense I want to separate selection of the TreeCell and the checking of the boxes.
I have some workarounds (implementing MouseAdapter and checking if the mouse click is close by where the checkbox is rendered, then emulate a check on the box by changing its appearence in TreeCellRenderer), but still I want to know if this can be done more directly. Thanks!
Why did they decide to do that instead of having multiple instances of TreeCellRenderer, each responsible for one cell?
This is a nice example of the flyweight pattern.
For a check box tree, I like org.netbeans.swing.outline.Outline, mentioned here, but other examples are available.
Addendum: Reading your question more closely, you ask:
In some sense I want to separate selection of the TreeCell and the checking of the boxes.
This is the correct instinct: The data (checked or unchecked) should be stored in the model (TreeModel), not the view (JCheckBox). The example uses instances of CheckBoxNode in it's (implicit) model, accordingly.