aspose file tools*
The moose likes Swing / AWT / SWT and the fly likes JTable JCheckBox Cell Editor works on strings -- badly Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "JTable JCheckBox Cell Editor works on strings -- badly" Watch "JTable JCheckBox Cell Editor works on strings -- badly" New topic
Author

JTable JCheckBox Cell Editor works on strings -- badly

S Baker
Greenhorn

Joined: Mar 03, 2007
Posts: 8
Here is another curiosity I don't understand about Cell Editors in a Swing JTable.

This is also TableExample3.java from the Demo area of the Sun JDK.

Here I changed the last column of the table from a Boolean object to a String which holds "true" or "false". Then I added a DefaultCellEditor using a JCheckBox in the constructor on the last column.

If you read the DefaultCellEditor code, it looks like the JCheckBox editor should support a String object set to "true" or "false".

And it sort of does. Try my example below. At first, all the values are displayed as strings. Then as you click them, they change to checkboxes -- sometimes -- you might have to click around a while before they change.

Why this behavior? Why do they first display as Strings? Why is the change to a checkbox intermittent?



pete stein
Bartender

Joined: Feb 23, 2007
Posts: 1561
I get the feeling that you may be confusing editing with rendering, and there's a big difference. To render a checkbox, the getColumnClass must return Boolean for the 4th column. Also, the getValueAt(...) must return a Boolean value for values from the 4th column. For instance:
S Baker
Greenhorn

Joined: Mar 03, 2007
Posts: 8
I definitely confuse editing with rendering because it is not clear from the documentation what these things do exactly. It seems plausible to me that the JTable could deduce the renderer from the editor for a column. In fact it does partially, if you run the code I posted.

I appreciate your explaining what to do. I wish it were more clear from the Java Docs how everything works. It seems you have to either read the Swing source code thoroughly or learn by looking at thousands of examples.

For example, doesn't it seem that the Java Doc for the getValueAt() method should mention that the type of object returned is used by the JTable to choose a default renderer to display the value, and that such and such a type is represented by such and such a control, etc...?

The rules seem so perplexing and capricious as to what a Swing component such as JTable does for you vs. what you have to do for yourself, that it almost seems easier to code everything from scratch. Who fires the events, the JTable, or me? Who uses getValueAt(), the JTable or me, etc. So much behavior that is not surfaced clearly.

When should I call JTable.createDefaultRenderers() for example?

I have a book on Swing and it fails miserably to give guidance on how anything really works or how to know what to do to effectively use it. Describing a bunch of objects doesn't impart intuition on how to use them, or what the underlying processes (engines) are that drive the GUI.

Sorry for the rant. Good documentation would save everybody (especially you experts) a lot of time. If you know of a great reference that really explains from the bottom up (such as, what is the contract that Swing has with the JVM that creates a GUI; how do the events get from the OS to Swing, etc.) I'd love to know about it.

(I'll stick to Q&A in the future )

Regards,
-SB

Rob Camick
Ranch Hand

Joined: Jun 13, 2009
Posts: 2183
    
    7
For example, doesn't it seem that the Java Doc for the getValueAt() method should mention that the type of object returned is used by the JTable to choose a default renderer to display the value,


No it shouldn't because the getValueAt() method is NOT used for this purpose.

If you read the JTable API for the getDeaultRenderer/Editor() methods you will see this is controlled by the column class.

Sorry for the rant.


I agree using a JTable is more complex then using other Swing components, but ranting is never a good idea. The fact that you don't understand the API or the tutorials or know how to search the forum/web for examples is a reflection on you, not on the information that is freely available.
S Baker
Greenhorn

Joined: Mar 03, 2007
Posts: 8
Rob Camick wrote:
For example, doesn't it seem that the Java Doc for the getValueAt() method should mention that the type of object returned is used by the JTable to choose a default renderer to display the value,


No it shouldn't because the getValueAt() method is NOT used for this purpose.

If you read the JTable API for the getDeaultRenderer/Editor() methods you will see this is controlled by the column class.

Sorry for the rant.


I agree using a JTable is more complex then using other Swing components, but ranting is never a good idea. The fact that you don't understand the API or the tutorials or know how to search the forum/web for examples is a reflection on you, not on the information that is freely available.


No it shouldn't because the getValueAt() method is NOT used for this purpose.


Maybe I misunderstood. It seemed Pete Stein overrode the getValueAt() method to return a Boolean, and that made the renderering behave more as expected. So I assume that the JTable is calling getValueAt() and checking the object type to choose a renderer.

I still don't understand the momentary left-shift of the checkbox when selecting. The code from JTable is:



which on the face of it looks like it wants to be centered.

The fact that you don't understand the API or the tutorials or know how to search the forum/web for examples is a reflection on you, not on the information that is freely available.


My feeling is that a different kind of documentation would vastly improve the learning curve, save a lot of time, and improve productivity overall.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19696
    
  20

S Baker wrote:So I assume that the JTable is calling getValueAt() and checking the object type to choose a renderer.

You assume wrong. As Pete said in his first reply to you, JTable is using the return value of it's model's getColumnClass() method to determine the renderer, not getValueAt().


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
S Baker
Greenhorn

Joined: Mar 03, 2007
Posts: 8
Rob Prime wrote:
S Baker wrote:So I assume that the JTable is calling getValueAt() and checking the object type to choose a renderer.

You assume wrong. As Pete said in his first reply to you, JTable is using the return value of it's model's getColumnClass() method to determine the renderer, not getValueAt().


I see. Thanks.
Rob Camick
Ranch Hand

Joined: Jun 13, 2009
Posts: 2183
    
    7
I still don't understand the momentary left-shift of the checkbox when selecting. The code from JTable is:


What has that got to do with this question?

My feeling is that a different kind of documentation would vastly improve the learning curve, save a lot of time, and improve productivity overall.


Since you continue to rant when it is not called for I will continue to reply.

You didn't understand the tutorial or the API. You didn't understand Pete's explanation and you didn't understand my explanation. What is the common denominator here? Maybe you should be spending more time reading and understanding the information and less time ranting. We should not have to waste time repeating ourselves (and I sure won't in the future) when we answer a question.
S Baker
Greenhorn

Joined: Mar 03, 2007
Posts: 8
Rob Camick wrote:
I still don't understand the momentary left-shift of the checkbox when selecting. The code from JTable is:


What has that got to do with this question?

My feeling is that a different kind of documentation would vastly improve the learning curve, save a lot of time, and improve productivity overall.


Since you continue to rant when it is not called for I will continue to reply.

You didn't understand the tutorial or the API. You didn't understand Pete's explanation and you didn't understand my explanation. What is the common denominator here? Maybe you should be spending more time reading and understanding the information and less time ranting. We should not have to waste time repeating ourselves (and I sure won't in the future) when we answer a question.


What has that got to do with this question?

You're right, that question was a separate thread.


Since you continue to rant when it is not called for I will continue to reply.

You didn't understand the tutorial or the API. You didn't understand Pete's explanation and you didn't understand my explanation. What is the common denominator here? Maybe you should be spending more time reading and understanding the information and less time ranting. We should not have to waste time repeating ourselves (and I sure won't in the future) when we answer a question.


jeez, excuse me.
S Baker
Greenhorn

Joined: Mar 03, 2007
Posts: 8
FWIW:

To get back to the original topic question, after reading some Swing source, I think I understand what seemed puzzling to me. Partly, it's because the DefaultCellEditor checkbox instantiation supports strings ("true"/"false") in the underlying data model, while the nested JTable.BooleanRenderer class does not.






Modifying the BooleanRenderer as follows:



makes the renderer and the editor work consistently with underlying string columns that represent boolean data with "true"/"false" strings. Then there is no need to modify the getValueAt() method to return a Boolean and it is sufficient to return the Boolean class in the getColumnClass() method to trigger the use of the BooleanRenderer. However that configuration is not consistent in the sense that the column class is a Boolean and the returned value is a String.

A better arrangement probably is to create a BooleanRenderer using the modified code and set the cell renderer for the appropriate column of strings. Then neither getValueAt() nor getColumnClass() need to be modified at all and the cell is displayed and edited as a checkbox while the underlying type is a String.



I appreciate the help in pointing out the roles of getColumnClass(), getValueAt(), and setting a cell renderer in addition to a cell editor for display of checkboxes in JTable.


 
wood burning stoves
 
subject: JTable JCheckBox Cell Editor works on strings -- badly