• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

No update/repaint with editable Panels in JTable

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

I have a JTable (initial: 1 column, 0 rows) with a custom cell renderer and cell editor.
Rows are added dynamically. Each cell value is an Object that extends JPanel. Each panel has a close-button, which actionPerformed method calls getTableModel().removeRow(rowIdx).
This should result in a new (table) view without the row whose panel invoked the close method.

Attached an example image that shows a table with to rows. The close buttons are marked in red. If I click on of them, it gets removed, but the view is not updated.
The view does not update itself before I change the frame size by hand (mouse drag&drop).
That means to me, that the remove method works, but the I cannot see it.

I already tried some of the getModel().fireXXX() methods and many repaint/revalidate/setvisible(false/true() methods, but nothing happens. I even tried to remove all rows and add the leftover panels in new rows. But the view does not update automatically at all.

Any help is highly appreciated
jtable-frame.jpg
[Thumbnail for jtable-frame.jpg]
Frame with JTabel and two rows
 
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Benne,
Welcome to the Ranch.

Please check your private messages for an important administrative matter.

Regarding your problem. Are you using/subclassing DefaultTableModel ? How are you removing the rows?
If you invoke DefaultTableModel#removeRow(int row) it removes the data and also updates the UI automatically. Are you using the same method?
 
Author
Posts: 986
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Benjamin Schwanke wrote:
I have a JTable (initial: 1 column, 0 rows) with a custom cell renderer and cell editor.
Rows are added dynamically. Each cell value is an Object that extends JPanel. Each panel has a close-button, which actionPerformed method calls getTableModel().removeRow(rowIdx).



I don't think I can recommend this approach.

For starters, I think it might be best not to use JTable in this situation but to use an actual JPanel with suitable layout mananger (BoxLayout, GridLayout). That way each cell would be "live" and not a "rubber stamp" pretending to be live. For the remainder of this post, though, I'll ignore this advice and presume you want the JTable implementation.

To do this "the JTable way" you typically wouldn't have the cell value be a Component such as JPanel. Instead you would have the value be some sort of model-like object (perhaps something simple like an array of values or hashtable of key/value pairs), then the TableCellRenderer and TableCellEditor would be a JPanel full of widgets that get configured to reflect the state model-like object.

Also, typically the close button (which is under the TableCellEditor's control) would not call removeRow(). Instead that button should complete the edit and return a value in getCellEditorValue() that your TabeModel's setValueAt() method would recognize, and it would be setValueAt() that would perform the deletion and call fireTableRowsDeleted().


I already tried some of the getModel().fireXXX() methods and many repaint/revalidate/setvisible(false/true() methods, but nothing happens. I even tried to remove all rows and add the leftover panels in new rows. But the view does not update automatically at all.



Calling fireTableRowsDeleted() should be adequate, but if you're calling it from someplace weird (like from a cell editor) you may want to wrap it inside invokeLater().
 
Benjamin Schwanke
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thank you for your advice.
You are right. The JTable approach is not very easy.
In the first place I made it with JPanels and GridLayout. This is more or less perfect for performance and interaction. The only drawback was that I could not resize JPanels within a main frame. JSplitPane doesn't work properly here, because I need many of them, i.e. nested split panes - which is very ugly and hard to manage.
If you have another good idea how to implement resizable panels within a main frame I am more than happy to get informed.
btw: I tried but didn't like the approach with internal frames, because they are way to flexible in this case. And I would have to add component listener the all panels to make them move and resize as far as another panel is moved/resized.
 
Brian Cole
Author
Posts: 986
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Benjamin Schwanke wrote:thank you for your advice.
In the first place I made it with JPanels and GridLayout. This is more or less perfect for performance and interaction. The only drawback was that I could not resize JPanels within a main frame.



I'm not sure what you mean here. I would think real panels would work better under resizing than JTable. How did JTable let you resize them? If you explain that, maybe I'll understand.

If you mean that they shouldn't all be required to be the same height then, yes, GridLayout is no good for you. You could use BoxLayout or possibly even FlowLayout.

If you mean they shouldn't be stretched then you probably want to put the GridLayout panel in the North of a BorderLayout panel.
 
Benjamin Schwanke
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Brian Cole wrote:

Benjamin Schwanke wrote:thank you for your advice.
In the first place I made it with JPanels and GridLayout. This is more or less perfect for performance and interaction. The only drawback was that I could not resize JPanels within a main frame.



I'm not sure what you mean here. I would think real panels would work better under resizing than JTable. How did JTable let you resize them? If you explain that, maybe I'll understand.


Oh, sorry. It's not a native method in JTable. I am using this one RowHeightResizer (http://woven-media.com/public/dist/camickr/src/RowHeightResizer.txt)

Brian Cole wrote:
If you mean that they shouldn't all be required to be the same height then, yes, GridLayout is no good for you. You could use BoxLayout or possibly even FlowLayout.
If you mean they shouldn't be stretched then you probably want to put the GridLayout panel in the North of a BorderLayout panel.



What I want:
Multiple panels one below the other in one application window as shown in the picture above(first post). No restricted heights. They should be vertically resizable by easy mouse drag&drop at the (south) border of each panel. E.g. if I resize (enlarge) one panel all others below should just move down. Like cell/row resizing in MS Excel that is in tables.
 
bacon. tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic