Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #38612

Re: Displaying a ragged array

Show all headers | View raw

On Mon, 24 Sep 2018 08:11:22 -0700, Eric Douglas wrote:

> On Wednesday, September 19, 2018 at 1:49:38 PM UTC-4, Martin Gregorie
> wrote:
>> 
>> As I said, the files its most likely to get used on are quite large  -
>> 14 columns by 5800 lines, they are around 450KB in size. These are
>> backup
> 
> That is really not a lot of data.  I just ran my test program with my
> custom grid (extended JTable).  It created a window with a menu, a
> searchable grid and 10 other components, ran a SQL query, populated the
> grid with 30 columns and 67047 rows, and displayed it all in under 14
> seconds from scratch (nothing cached).
> 

Yep, you're dealing with a lot of rows and columns but, out of curiosity, 
what's the table size in kb? What length is the data in your widest and 
narrowest columns?

Another interesting comparison would be to know how 'skittish' you find 
scrolling with the scrollbar. I wrote a maintenance app for my mail 
archive, based on a PostgreSQL database. When scrolling up and down the  
16,700 addresses in the database its twitchy enough to make showing a 
specific address relatively difficult - the scrollbar slider is the same 
depth as a line of text in the JTable at this point and so a very small 
slider movement scrolls past quite a lot of lines. I assume you have the 
same problem.

> Loading data from a text file (or SQL table) should be pretty fast.
>
My roster editor sets up six empty rosters containing 106 rosterees and 
52 days (rows) per roster in 5.6 - 7 seconds on the first run of the day 
and just 2.2 seconds if its subsequently stopped and restarted. It 
restores a backup of all six completed rosters in about a second (0.9-1.1 
secs). All figures from my Seiko sport stopwatch. The restore involves 
loading the backed up data into class instances that were created when 
the program started up and displayed the set of unpopulated rosters.

I think this shows that, for the CSV editor, the time spent reading the 
file is likely to be a lot less than the time spent constructing the 
class instances used to contain and to display the data.
  
> use the Apache POI to save to xlsx format through a custom class I wrote
> to keep it clean and it does take a lot longer, so the only reason to do
> that generally is if someone is also using a spreadsheet program to
> maintain the data.
> 
Yes, agreed.

> I'm certain my API can do everything you would need and do it
> efficiently but I have spent years developing it, so it's hard to say
> the best way if you're writing from scratch and want it up and running
> quickly.
>
I'll try a JTable in a JScrollPane first, initially without editable 
cells. If it can show my data in a reasonably tidy way, that's job done. 
If not, I'll use a variation on the way the roster editor works, which is 
to add a row of class instances to the JViewport as each line of the CSV 
file is read. My intnetion to try this approach first is why my Datastore 
class extends AbstractTableModel.

Your experience shows this may be fast enough to be acceptable, which 
would be great.  However, if it is agonisingly slow OR using scroll bars 
on such a large number of rows is too skittish then I'll try using a non-
scrolling window that is prefilled with rows of cells that can be:

- unused, in which case they'll all be invisible

- used for a comment line which shows the line number and a single
  editable text field with white text on a dark blue background

- used for a data line which shows the line number and an editable text
  field showing black text on a pale grey or white background

Scrolling would work by changing the top left row number and field number 
to move the viewpoint relative to the top left of the ragged array and 
painting a window-full of rows and fields starting from that position. 
Like a spreadsheet the line numbers on the left would always be visible, 
and the refresh after a movement should be should be fast.

Its probable that all fields will be JButtons so that the user clicks the:
 
- line number to insert new row(s) 

- top (field number) row to insert new column(s)

- a field to edit it

Like a spreadsheet, editing will be done will be in a wider, edit field 
just under the menu bar - again, like a spreadsheet.

> Did you want one comment for each table row or multiple?
>
No limit on how many comment lines are used or where they are in the file.

> How long can a comment be? 
No (sensible) limit

> Can it contain linefeeds? 

No. If you want a comment block, you use multiple comment lines, each 
preceded by the comment marker character and the comment line(s) may 
contain field separators, which are treated as just another character in 
the comment line. Maybe there are CSV files that don't work this way but 
I don't remember seeing one. 

Blank lines are OK too: they are treated as empty data lines.

Using the editor to add a row sticks a blank line into the matrix. The 
user then leaves it blank or adds one or more fields: if the row only has 
one field whose text starts with a comment marker its a comment line (and 
adding a second field will be treated as an error). Otherwise its just 
another CSV line, initially with a single field in it. 

Similarly, editing the first field in a row to make it start with a 
comment marker is also treated as an error.  

> Do you need to see the entire comment at once to edit it?
>
Not in the display area, but the field editor will have a much wider 
editing area. Datastore stores a comment line as a row with a single 
(large) text field. The first character in this field determines whether 
the row is treated as a comment line or a row of CSV fields. The comment 
marker is configurable but cannot be the same as the field separator 
character, which is also configurable.

> Do you want to see multiple entire comments at once?
>
Yes, that's implied.

> You'll save time on coding if you can "flesh out" the design more.
> 
Indeed, which is why so far I've concentrated on making the Datastore 
class work as I've just described. Now I'm happy with that, its time to 
add code to load/save DataStore content using my existing and well-tested 
CSV class and then to start work on the display appearance and logic 
before finally implementing the field editing facility.

> You need a treetable control if you need to display spreadsheet style
> data with hidden data (collapsible rows).
>
I don't think I need collapsable rows, but there will be a default column 
width - this will limit the display width of any column (and may cause a 
'+' or '>' to be displayed at the right end - this is currently 
undecided). 

The whole field can always be seen by using the field editor.

Later, I'll also add a capability to let the user to inspect the first 
few lines of the file while they set the comment marker and field 
separator characters.
 

-- 
Martin    | martin at
Gregorie  | gregorie dot org

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Displaying a ragged array Martin Gregorie <martin@mydomain.invalid> - 2018-09-16 22:17 +0000
  Re: Displaying a ragged array Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2018-09-17 16:00 +0200
    Re: Displaying a ragged array Martin Gregorie <martin@mydomain.invalid> - 2018-09-17 19:32 +0000
      Re: Displaying a ragged array Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2018-09-17 23:29 +0200
        Re: Displaying a ragged array Martin Gregorie <martin@mydomain.invalid> - 2018-09-17 23:43 +0000
          Re: Displaying a ragged array Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2018-09-19 18:12 +0200
            Re: Displaying a ragged array Martin Gregorie <martin@mydomain.invalid> - 2018-09-19 17:49 +0000
              Re: Displaying a ragged array Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-09-19 14:25 -0400
                Re: Displaying a ragged array Martin Gregorie <martin@mydomain.invalid> - 2018-09-19 19:29 +0000
                Re: Displaying a ragged array Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2018-09-20 15:30 +0200
                Re: Displaying a ragged array Martin Gregorie <martin@mydomain.invalid> - 2018-09-20 15:06 +0000
              Re: Displaying a ragged array Eric Douglas <e.d.programmer@gmail.com> - 2018-09-24 08:11 -0700
                Re: Displaying a ragged array Martin Gregorie <martin@mydomain.invalid> - 2018-09-24 17:52 +0000
                Re: Displaying a ragged array Eric Douglas <e.d.programmer@gmail.com> - 2018-09-24 12:01 -0700
                Re: Displaying a ragged array Martin Gregorie <martin@mydomain.invalid> - 2018-10-23 21:00 +0000
  Re: Displaying a ragged array Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-09-17 10:17 -0400
    Re: Displaying a ragged array Martin Gregorie <martin@mydomain.invalid> - 2018-09-17 19:46 +0000
      Re: Displaying a ragged array Martin Gregorie <martin@mydomain.invalid> - 2018-09-17 23:53 +0000

csiph-web