• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JTable JCheckBox Cell Editor works on strings -- badly

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?



 
Bartender
Posts: 1561
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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

 
Rancher
Posts: 3324
32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Sheriff
Posts: 22781
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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().
 
S Baker
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Rancher
Posts: 3324
32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.


 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic