Skip to main content

Multi-Line rows for a JTable

12 replies [Last post]
mwroderick
Offline
Joined: 2007-03-02

I currently have an application that uses a JTable to display a list of user-selected fields( the user can select what data fields to see from a list of approx 150 possible data field). And all this is working just fine, but now I am being asked to make the data display on multiple rows per row of data. This stems from the user having way more data than can fit in one row, and wanting to be able to review it all without scrolling back and forth accross the screen. And as a complicating issue, each column can and usually is of a different width. So my question is this: Are there an suggestions on approaches that can be taken to meet this multi-line row requirement?

Thanks

Mike

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ckiick
Offline
Joined: 2014-03-21

7 years later...I have the same problem and there still doesn't appear to be an out-of-the-box solution. I've looked at various Jtable extensions and none of them offer multi-line rows. A few apps I've seen have them, but they are not based on Jtable, and lack most of its features.

Anything new on this since the OP?

Thanks,

mwroderick
Offline
Joined: 2007-03-02

I implemented the changes I described in my March 2007 reply into production years ago. They have been successfully used by both our power users and our data miner type users, and all the others as well. It took quite a bit of adjusting to get things right, especially some issues around the clipping rectangle(in an early version, users were required to manually ensure that the last display line was the longest display line to get the clipping rectangle to work right), but it does work, and once it was implemented, it has not hardly been changed since.

ckiick
Offline
Joined: 2014-03-21

That's realy cool. I don't suppose there's some example code I could look at?

mwroderick
Offline
Joined: 2007-03-02

I have changed projects several times since the time I wrote that code, and I no longer have access to the code either. All I can tell you is to just work with it and you can make it work... Conceptually its not that complicated, but it does take some time to get the details just right.

mwroderick
Offline
Joined: 2007-03-02

Just to keep anyone who might be interested aware, I have come up with a scheme which appears to be working so far. I have overriden the getCellRect on JTable, getHeaderRect on JTableHeader, and the paint methods on the BasicTableUI and BasicTableHeaderUI classes. I am not 100% sure this will work for me, but so far I do have the data displaying a sigle row of data into multiple rows on the screen. Thanks for you help so far, and if anyone see's any gotchas I should watch for with this approach, I would appreciate the heads up.

Mike

tarbo
Offline
Joined: 2006-12-18

The only 'gotcha' I can reasonably think of is [i]possible[/i] compatibility problems with more advanced PLAFs. Check with a few different ones (most notably Metal and whatever Os you're running on) to be sure you have the desired effect on all UIs. But since you already went through Basic*UI classes, I take it you got this far.

Other than that... caution with scroll panes and mouse events.

But kudos on getting it working. I've been messing around with JTables myself lately and it usually is a [i]lot[/i] of finagling and subclassing.

david_hall
Offline
Joined: 2003-06-12

I'd say you have a real problem, or rather, several real problems.

the first is that you have to map several visible rows of a table to a single row of data -- JTable and JXTable assume a 1:1 mapping. This will be a real problem if you want sorting|filtering|searching.

the second is that JTable and JXTable assume (by default) that columns are heterogeneous -- if you need to store multiple datatypes in a single column, or use different renderers|editors for cells in a single column, I'm reasonable certain that you'll have to override JTable|JXTable.

I think this is all doable, but it may not be easy. As a starting estimate, look at every method that takes a (row,col) position -- you'll probably have to override all of them to deal with one or both of the above cases.

You might be able to start with an extension of JXTable that overrides the model:view mapping methods, and routes all of the others that use view positioning through your new map method.

rah003
Offline
Joined: 2004-05-26

That really depends on what your users do. From your description it looks like they are only looking at the data and not editing at all. If so I would think of rewriting this part of the app as JList and using some more complicated layout for each of the list items. Do they ever select all 150 fields? If so that could easily fill the screen on its own.Do the users compare data in different rows against each other? If so, you may want to highlight discrepancies for them to make it easier. Do they look on each row on its own only? Why not to have a fixed form and just change the data as they browse through.

> but now I am being asked to make the data display on multiple rows per row of data.

I guess you are not asking just about wrapping text in single cell over multiple lines, right? You can split one data row into multiple table rows and recalculate widths to match the biggest one, but then you will ultimately run into other problems like what about a column headers (what would be a meaningfull title for a column) and so on.

mwroderick
Offline
Joined: 2007-03-02

> That really depends on what your users do. From your
> description it looks like they are only looking at
> the data and not editing at all.

Well the current version only has 1 column that is editable, and it is a boolean field; however, part of the same effort is adding 3 more editable fields that the users will be keying data into based upon review the rest of the fields that are displayed on the screen. This is what is driving being able to see all the data without scrolling, because they want to look at the aprox 30-40 fields that they have selected for review, and enter data into these new fields without using the mouse, so they can do it as fast as possible.

> If so I would think
> of rewriting this part of the app as JList and using
> some more complicated layout for each of the list
> items. Do they ever select all 150 fields?

No, typically they select 30-40 that they need for their job function, but there are several user groups using the system, and they each have a different set of fields that they use.

> If so that
> could easily fill the screen on its own.Do the users
> compare data in different rows against each other?

In general no; however, they keep an eye out for data consistancy errors, as they go. And to add more info, they quite commonly have it set up with 1,000 - 20,000 rows of data they are reviewing at a time. We have already solved the issues with this by using a Stateful Session Bean to cache the data into managable hunks.

> If
> so, you may want to highlight discrepancies for them
> to make it easier.

No, but they do want to highlight specific fields, but not most which complicates the multiple rows with recalculated widths theory you had below.

> Do they look on each row on its
> own only?

Yes and no. Primarily they are working each row, one at a time, but the faster users have the ability to scan ahead, and review faster than they can key... Which is amazing to watch, cuz I would get confused!!! and the faster users can review all the fields and do the input in less than 6 seconds per row.

> Why not to have a fixed form and just
> change the data as they browse through.

We have many different user groups, each group has a different set of fields they use, and so we have this flexable solution where they pick the fields they need rather than having us build a seperate screen for each of the users. In general this solution is working for us, but we just need to better accomidate the faster power users.

>
> > but now I am being asked to make the data display
> on multiple rows per row of data.
>
> I guess you are not asking just about wrapping text
> in single cell over multiple lines, right?

Nope, I only wish it was that simple.

> You can
> split one data row into multiple table rows and
> recalculate widths to match the biggest one, but then
> you will ultimately run into other problems like what
> about a column headers (what would be a meaningfull
> title for a column) and so on.

I had considered this solution, however it seems like a path fraut with peril. Not only the column header issue you considered, but the data field high-lighting issue, the resizing of a column issue, and even something as simple as the issue of how do I make it look like a table without having lines in the middle of the data. At this point, I am considering this a path to take only when all others are exhausted!

Thanks for your thoughts, but I still don't have an answer to how can I get a row of data in a JTable to span multiple display rows?

Thanks,

Mike

rah003
Offline
Joined: 2004-05-26

Hi Mike,

with all the additional info you have provided the only reasonable solution I can see is to forget about jtable and use jlist with your own design/layout of the items that would reflect what fields you need to show on where. The editable ones you can manage on your own since there are not too many. Something along the lines of "Extreme List" demo by Scott http://weblogs.java.net/blog/zixle/archive/2006/12/extreme_list_vi.html
It will be some work to write it the way to take care of all the choices users can make in what fields to display, but seem me easier to do and to maintain then anything you would have to do with raw table.

Cheers & good luck,
Jan

i30817
Offline
Joined: 2006-05-02

Probably not very efficient:
Take this tecnique: http://david.fallingrock.net/2005/06/30/wrap-jlabel-text/
using a entended cell renderer

mwroderick
Offline
Joined: 2007-03-02

i30817,

My problem is one of trying to wrap the entire row over multiple lines, not one of trying to wrap the data in a single cell over multiple lines.... But thanks for trying.

Mike