Eric Snell

One way is to subclass AbstractTableModel, contain references to your various lists in your new class, and access those lists as appropriate from the methods you must override to implement AbstractTableModel.

Override boolean JTable.isCellEditable(int row, int column) and return false when the row is 0.

or

Override boolean TableModel.isCellEditable(int rowIndex, int columnIndex) and return false when the row is 0.

Those are probably the most straightforward ways.

How about java.awt.MouseInfo.getPointerInfo() ?

How about creating an interface your frames can call to populate the menu. You can implement the interface to correctly populate your menu. The interface implementation could be the menu itself, or better yet an object that contains the menu and is responsible for populating it. Your frames would only depend on the interface, which should be relatively simple.

Don't load your JTree on the Swing thread. Use a background thread to build your model, then set it into your JTree on the Swing thread using SwingUtilities.invokeLater(). If your model is already in your JTree while updating, make sure your fire your update event on the Swing thread.

A table cell editor has a method, getTableCellEditorComponent, that you can override. Populate your combo box before returning it from that method.

It's hard to envision exactly what the problem is. My guess is that what your are seeing is related to the preferred size of the components. Try setting them all equal and see if that helps.

public void setPreferredSizeEqual(final JComponent[] list) { final Dimension prefSize = new Dimension(0, 0); for (JComponent comp : list) { prefSize.width = Math.max(comp.getMinimumSize().width, prefSize.width); prefSize.height = Math.max(comp.getMinimumSize().height, prefSize.height); } for (JComponent comp : list) { comp.setPreferredSize(prefSize); } }

Invoke dispose() on the Frame when you're done with it. It is not sufficient to hide it. Dipose causes the native resources to be freed.

Originally posted by Craig Wood:
You can go back to the older way of using a WindowListener:
chatFrame.addWindowListener(new WindowAdapter() { public void windowClosing(WindowEvent e) { // close files // clean up System.exit(0); } });

If you leave the default close operation as JFrame.EXIT_ON_CLOSE, you don't need the call to System.exit() in your windowClosing() method.

Because you set the min and max sizes to the same value.

Before you hide your column, save the initial min and max, then when you restore your column reset the min and max to what you save. If you don't want to save the values, try setting min to 0 and max to Integer.MAX_VALUE.

I have a bunch of code for sizing, hiding, restoring, and persisting table column information. If you want I'll email it to you.

Originally posted by Suresh Selvaraj:
...
If its a JSP/Servlet application, we can maintain the data in Http Session and finally save the data when the user pushes SAVE BUTTON in SCREEN 1.

Since this is a Swing based application, I need to save the data in each screen to the database, and when I navigate from Screen 3 to screen 1, I need to read the data from database etc...

...

In the Swing based app, why do you need to save the data to the DB? Why not just maintain it on the client until you have all the data you need and then perform the one transaction? Is maintaining data in the http session so different from that? What are your failure scenarios in each situation, how do you handle them, and how is the user experience different in each case? It seems the http session scenario is a more complicated architecture since the context must be maintained across several stateless calls from a client.

What about the costs associated with user experience? Mustn't that factor in to any discussion regarding cost? Some tasks are easier in a rich GUI environment, while some can be done in the simple, yet restrictive, browser environment.

Well, it's a little hard to answer without knowing exactly what you're trying to accomplish.

You can add a method to your ComboBoxB model that makes the necessary changes without firing an update event until all processing is completed. This would allow you to make multiple changes to the model and then fire 1 event.

pseudo code:
handle event from ComboBoxA call ComboBoxB model remove all items add appropriate items fire event
I prefer to make changes to my models by calling the model itself, as opposed to calling the GUI widget.

Hope that helps.
[ June 15, 2004: Message edited by: Eric Snell ]

Why call Servlets? What would that add?

The architecture you describe sounds OK. Is there some code duplication between a web interface and swing interface you're trying to address? Otherwise, I don't know why you'd introduce more complexity if it's not needed.

Originally posted by fei long:
I have two JComboBox say 'A' and 'B'. I want event change(item selection) on 'A' to trigger automatic change on another JComboBox 'B'. Items(contents) in 'B' are dynamically read from somewhere. I looked API but didn't find suitable methods. I am sure there must be a way to do the job, but couldn't figure it out. Can anyone please give me suggestion or any code snippets would be appreciated.

Add an ActionListener to combobox A. When it's actionPerformed method is invoked you can call getSelectedItem() on it and select an item in combobox B based on that.