Need an inexpensive higher-powered version of JTable

I'm looking for a free or inexpensive upgrade component along the lines of
JTable.

The most important feature to me is to easily be able to sort by column.

I realize that this can probably be added to JTable (pointers on/to source
code that does that are welcome) but I'd like to do it as easily as possible
and that probably means getting a table package.

This functionality is going into a program that will be either freeware or
shareware so I can't afford to pay the multi-thousand dollars that is being
charged for commercial components.

Thanks,

Dave Blickstein

P.S. The program I'm developing is called "Barfly Tournament Director".
It's basically a program
to direct sports tournaments oriented towards meeting new people -
i.e. assigning people
to new teams in each "round" to maximize the number of people they
meet.

A fuller description of the Barfly concept is available at

www.volleyballvacations.com/Barfly.htm

I welcome inquiries/interest in this.

for how to add this to JTable, see:

http://java.sun.com/docs/books/tutorial/uiswing/components/table.html#sorting

Pete

Um, yes, that may be fine if you just want to look at the data on the
screen, but it's completely broken as far as row selection is concerned, so
no use if you want to select a row in the table and then hit a button which
is supposed to do something to that row. The architecture is broken -
there's no way to stick in a transparent data manipulator that does sorting.
I've done it by subclassing JTable to make a SortableJTable, but my client
owns the code so I can't give it away.

--
Tim Ward
Brett Ward Limited - www.brettward.co.uk

It depends on what the something is; added, editing or deleting the row
contents might require a resort, or it might be OK to leave the data
scruffy until a sort is demanded by the user.

To maintain selection of the data corresponding to a selected row, you
would need to cache the indices of the selected rows before the sort,
perform the sort, then select the rows for the cahced indices; this
would require the TableSorter to be able to navigate to each table it
sorts; either from the event or by keeping a reference to the table
passed to addMouseListenerToHeaderInTable, depending on the number of
tables it has to deal with.

If your data model maps each row to an object, then adding
public int getIndexOfRow(int row) {return indexes[row];}
to will allow you to navigate to the correct underlying object from the
row.

Writing from scratch one could make a better architecture, but this may
well suffice, and only requires adding a few extra lines to the publicly
available code.

Pete

Somewhat breaks the idea that the sorter table model is transparent, as
claimed in the tutorial, doesn't it.

In my case I wanted to resort automatically as real time data arrived over
the network.

Yes, if an application requires the use of methods outside the
tablemodel interface then any implementation which is transparent for
the tablemodel interface might not be transparent over some other
interface. If the model implements another interface with a
getMyRowObject(row) method by calling getMyRowObject(indixes[row]) on
the underlying model, then it would be transparent for that interface too.

You have said that your implementation, which appears to be a better
solution to a slightly different problem, is not available as a solution
to the OP as it is commercial. Could you at least describe the
architecture you're using with sufficient detail for the OP to
implement, instead of just saying 'I've got a better way of doing this,
but I'm not giving you my code'?

Pete

You'll find the code into John Zukowski, Definitive Guide to Swing for
Java 2, APRESS. It could be easily extended to sort by multiple columns.
Perhaphs you'll find the book in the library.

Bye, Carsten
--
Dipl. Ing. Carsten Zerbst | carsten...@atlantec-es.com

SortableJTable derives from JTable and overrides things as necessary to keep
a row index lookup table in the same way as JTable keeps a column index
lookup table (for when users move columns around); this is obviously similar
to the tutorial implementation apart from keeping the index in the table
rather than the model. As far as possible I kept the interface to dealing
with rows the same as JTable's interface to dealing with columns (I don't
actually *like* this interface, and wouldn't have designed it that way
myself, but consistency seemed, just, the overriding factor.) This gives you
a convertRowIndexToModel as a method on the table analagous to the existing
convertColumnIndexToModel. (Yuk. But like I said, I went for consistency,
and at least it's no less transparent than JTable was already.) The stuff
for detecting mouse clicks in the column header and displaying the little
triangle was nicked from other sortable table implementations. (In fact I
keep a complete history of all columns that have been used for sorting, and
the sort directions, so that by clicking in the right order on the right
column headings the table can be sorted on multiple columns (regardless of
whether the library sort I ended up using was stable or not).)

The SortableJTable has an "automatic sort" property. If turned off a change
to the data removes the little arrow from the column header and the table is
now unsorted. If turned on the table is resorted automatically on data
changes, with the selection model being kept in track as described by
someone else in an earlier post. (This gives good enough performance for my
application; but it's obviously going to be a bit heavy if you've got many
and frequent incoming data changes so YMMV.) Application: where table rows
represent the status of external widgets (outside the computer) the rows can
automatically sort themselves to put the widgets with the most serious alarm
status at the top, so if something goes into an alarm state it moves up to
the top of the table.

I've added a couple of methods for getting and setting the entire selection
model in data model row coordinates, because one application of this
sortable table involved switching between a table view and a list view of
the same data, and adding sorting made it necessary for the application to
patch up the selection model on switching views (with the normal JTable it
could use the same list selection model for both views without even knowing
when the views were switched - this is the one thing I've discovered (so
far) that I've made worse).

Minimum usage is:
(1) define a SortableJTable instead of a JTable
(2) pass any row coordinates from the selection model through
convertRowIndexToModel before using them, like you already have to for
column coordinates.

So far none of the above changes anything you might want to implement in
your table model, but the following features, if you choose to use them, do
affect the table model:

I've defined a SortableTableModel interface; the table model can optionally
implement this, and if it does it can say which columns are and aren't
sortable by returning a flag from a new method isColumnSortable (otherwise
all columns are sortable). Plus a CaseInsensitiveColumnData object you can
return from getValueAt which wraps any Object and causes the column to sort
case insensitively by doing a case insensitive comparison on the Object's
toString.

Plus, of course, the whole thing is an intensely frustrating waste of time
re-inventing wheels anyway, as the operating system has a perfectly good
sortable table that Java won't let you use.