• Post Reply Bookmark Topic Watch Topic
  • New Topic

Jtable invalid  RSS feed

 
George Nieuwoudt
Greenhorn
Posts: 8
Eclipse IDE Firefox Browser Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peeps

I am sitting with a very frustrating situation regarding my JTables which goes invalid and do not behave as it should, i might be missing the correct way to work with them or somewhere it might not update correctly.

The scenario:
I have a class for showing all iterations and version of a file(Data management), when I choose which file I want to view all versions of I call my default created class for creating frames and then the frame class calls the relevant table class. Now when I open all the versions of my selected file it opens a new window showing all the versions of that file, when I close it and select another file to view all the versions for some reason the newly created table class with new parameters still tries to show me the previous table and info, it does not update the newly created table and search criteria.

I use jscrollpane as a container.
I do not have an exit method on the all versions frame I use the setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);

Does this not set all the objects to null on exit? And what am I missing to get the newly created table on the scrollpanel?
1.PNG
[Thumbnail for 1.PNG]
first time i open the frame for all versions
2.PNG
[Thumbnail for 2.PNG]
close the frame and open it again rebuilding the table
 
Paul Clapham
Sheriff
Posts: 22374
42
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
George Nieuwoudt wrote:I do not have an exit method on the all versions frame I use the setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);

Does this not set all the objects to null on exit? And what am I missing to get the newly created table on the scrollpanel?


Well, no. Apart from the fact that it's impossible to "set an object to null", did you read the documentation of the setDefaultCloseOperation method to see if it did anything like that?

The usual way to re-fill a JTable with a completely new set of data is to create a new TableModel containing that data and call the JTable's setModel() method to put that model into the JTabel. Strategies which include creating new versions of the GUI components are excessively clumsy.
 
George Nieuwoudt
Greenhorn
Posts: 8
Eclipse IDE Firefox Browser Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

Thanks for the reply, so through my investigation i found this regarding the dispose method for the frame:
Releases all of the native screen resources used by this Window, its sub components, and all of its owned children. That is, the resources for these Components will be destroyed, any memory they consume will be returned to the OS, and they will be marked as undisplayable.
The Window and its sub components can be made displayable again by rebuilding the native resources with a subsequent call to pack or show. The states of the recreated Window and its sub components will be identical to the states of these objects at the point where the Window was disposed (not accounting for additional modifications between those actions).

So how i managed to solve this issue was i created a new temporary JTable and pulled the latest jtable from the viewport on the scrollpanel as a workaround, but still there was some concern over how i clumsily used my resources with closing and reopening my mainstream objects, so i created an interface for the global objects to not recreate unnecesary objects. Was this a better way since you pointed out or am i still to clumsy?


 
Martin Vajsar
Sheriff
Posts: 3752
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
George Nieuwoudt wrote:Releases all of the native screen resources used by this Window, its sub components, and all of its owned children. That is, the resources for these Components will be destroyed, any memory they consume will be returned to the OS, and they will be marked as undisplayable.
The Window and its sub components can be made displayable again by rebuilding the native resources with a subsequent call to pack or show. The states of the recreated Window and its sub components will be identical to the states of these objects at the point where the Window was disposed (not accounting for additional modifications between those actions).

As far as I know, all of Swing is made from lightweight components. So there are practically no native resources to free. The only ones Swing allocates are native windows for its frames (or so I believe).

If you just want to display a new data in a JTable, just setting a new table model (as Paul has already suggested) would be fine. There isn't going to be a single native component created or destroyed because of this. (Well, there might be, if you assigned a heavyweight renderer to the table. Hopefully you aren't doing that.)
 
m Korbel
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
- not those Objects never will be GC'ed, this Object can't be finallize()'d, by default there isn't difference betweens setVisible(false) and setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);

- these Object with all referencies to another Object(s) stays in JVM memory untill current JVM instance exist

- for this logics is required to override WindowListener, e.g. add JFrame.getContentPane.removeAll() in windowClosing event

- this is booking example about usage of JDialog(Frame owner, String title, boolean modal)

- create this JDialog only once time, reuse that for another action

- use default value for CloseOperation... HIDE_ON_CLOSE,

- then you have to

- add WindowListener and to override windowClosing

1. with setVisible(false) for the same actions, then only to reset value in all JComponents, notice before its container will be hidden, otherwise you can to see previous value for very small period, and then they are (quite immediatelly) will be repainted to proper, current value

2. JDialog.getContentPane.removeAll() again before setVisible(false), then next action should be contains JDialog.pack() too

- next JDialog.setVisible(true) should be delayed and wrapped into invokeLater(), prepare all values, set to the JComponents, then block invokeLater contains JDialog.setVisible(true)
 
George Nieuwoudt
Greenhorn
Posts: 8
Eclipse IDE Firefox Browser Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you all for the input, i really appreciate it and used the lightweight components to my advantage of not recreating components which was unnecessary.

I realized that my problem was not using the correct reference to the new jtable, that's why it came up as invalid the whole time.

as for lightweight components i read up on it and what the jvm does with all the objects on a frame when disposing the frame which led me to another more effective way of using all this functionality which i previously did not understand fully.

so what i did now was not create another instance of my frame and recreating the table, i dispose the frame and then create new table model and set the new model to the originally created jtable.so i am still referencing the same table i just add the new model.

does this make better sense, or am i still missing the concept of how i previously worked with alot of clutter and unnecessary recreation of objects which i can reuse ?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!