aspose file tools*
The moose likes Swing / AWT / SWT and the fly likes No update/repaint with editable Panels in JTable Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "No update/repaint with editable Panels in JTable" Watch "No update/repaint with editable Panels in JTable" New topic
Author

No update/repaint with editable Panels in JTable

Benjamin Schwanke
Greenhorn

Joined: Aug 28, 2009
Posts: 6
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



[Thumbnail for jtable-frame.jpg]

Maneesh Godbole
Saloon Keeper

Joined: Jul 26, 2007
Posts: 10523
    
    9

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?


[How to ask questions] [Donate a pint, save a life!] [Onff-turn it on!]
Brian Cole
Author
Ranch Hand

Joined: Sep 20, 2005
Posts: 862
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().

bitguru blog
Benjamin Schwanke
Greenhorn

Joined: Aug 28, 2009
Posts: 6
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
Ranch Hand

Joined: Sep 20, 2005
Posts: 862
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

Joined: Aug 28, 2009
Posts: 6
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: No update/repaint with editable Panels in JTable