(I've posted some of this on the Works list. But in somebody else's thread. And now I got new questions. So a new thread is in order. And by posting on the common list I hope to get the attention of more people.)

I want my new app to be able to present large result lists - perhaps tens of thousands of hits, each with a few tens of bytes of data. The list should be presented in an edit table. (I might use a list box if I somehow hit a wall with edit tables.)

The usual way of handling this situation is to

- save] the list to SYSLISTS (or some other table)

- divide the list into manageable chunks of fixed size

- present one chunk at a time…

- …along with controls that let the user switch to a different chunk (e.g, a "VCR" interface).

I've used this approach myself, in a web app.

(Just exactly how to divide up the list is a matter of taste. It can be done "physically", with suitably sized, tailormade SYSLIST rows. Or it can be done with an array of pointers into standard SYSLISTS rows.)

For a web app chunks are fine. But this new app of mine is not a web app, and I want to do away with chunks - as far as the user is concerned. To the user it should seem as if the whole list is present in the edit table. In reality there might be just a suitable chunk of data present, but when the user scrolls outside that chunk of data, some handler would retrieve more data from SYSLISTS and the queried table, and reset the contents of the edit table. The edit table contents would be sort of a sliding window onto a much larger list that is stored in tables.

Now to my questions:

- How much data can one fit into an edit table? Postings say edit tables can be filled with more than 64K of data by using the INSERT message. But I want my edit table to be multi-select as well, and my notes from earlier experiments with this say I can't get both. True or untrue? Does anybody know?

- Let's say I could fit a lot of data into my edit table. How would it perform? Sluggishly? - Of course my approach with keeping just a chunk in the edit table and retrieve from tables on demand could lead to sluggish performance - if the user scrolled quickly in one direction, or made large, random jumps.

(Note that with my approach the edit table would load fairly fast, because not all data would be retrieved at once. An edit table with all the data loaded would need more time to get going (or more sophisticated programming than I'm capable of). With my approach the performance drop (or fluctuations) will come later, when the user scrolls or jumps sufficiently far, and new data must be read and Xlate-ed. In an edit table with all the data loaded, scrolling would at worst lead to paging of content to files, which is a fairly fast and simple operation. I believe.)

( Note that with my approach there is no paging of content. What I'm thinking of is: If my users do a lot of long jumps back and forth, the same chunks of display data would have to be generated (read and Xlate-ed) again and again. Then it could pay to save the content already generated. )

- Again - let's say I can get more than 64K of data into my edit table. But how much more? What if there are 50,000 hits, each with 40 Ks of display data? That's 2 megs altogether! Can an edit table really handle that much data?

- Oystein -

Øystein Reigem,

Humanities Information Technologies,

Allégt 27,

N-5007 Bergen,

Norway.

Tel: +47 55 58 32 42.

Fax: +47 55 58 94 70.

[email protected]

Home tel/fax: +47 56 14 06 11.

Today's listening suggestion: Bad Company (no, not that Bad Company): Inside the Machine (BC Recordings)

(I've posted some of this on the Works list. But in somebody else's thread. And now I got new questions. So a new thread is in order. And by posting on the common list I hope to get the attention of more people.)

I want my new app to be able to present large result lists - perhaps tens of thousands of hits, each with a few tens of bytes of data. The list should be presented in an edit table. (I might use a list box if I somehow hit a wall with edit tables.)

The usual way of handling this situation is to

- save the list to SYSLISTS (or some other table)

- divide the list into manageable chunks of fixed size

- present one chunk at a time…

- …along with controls that let the user switch to a different chunk (e.g, a "VCR" interface).

I've used this approach myself, in a web app.

(Just exactly how to divide up the list is a matter of taste. It can be done "physically", with suitably sized, tailormade SYSLIST rows. Or it can be done with an array of pointers into standard SYSLISTS rows.)

For a web app chunks are fine. But this new app of mine is not a web app, and I want to do away with chunks - as far as the user is concerned. To the user it should seem as if the whole list is present in the edit table. In reality there might be just a suitable chunk of data present, but when the user scrolls outside that chunk of data, some handler would retrieve more data from SYSLISTS and the queried table, and reset the contents of the edit table. The edit table contents would be sort of a sliding window onto a much larger list that is stored in tables.

Now to my questions:

- How much data can one fit into an edit table? Postings say edit tables can be filled with more than 64K of data by using the INSERT message. But I want my edit table to be multi-select as well, and my notes from earlier experiments with this say I can't get both. True or untrue? Does anybody know?

- Let's say I could fit a lot of data into my edit table. How would it perform? Sluggishly? - Of course my approach with keeping just a chunk in the edit table and retrieve from tables on demand could lead to sluggish performance - if the user scrolled quickly in one direction, or made large, random jumps.

(Note that with my approach the edit table would load fairly fast, because not all data would be retrieved at once. An edit table with all the data loaded would need more time to get going (or more sophisticated programming than I'm capable of). With my approach the performance drop (or fluctuations) will come later, when the user scrolls or jumps sufficiently far, and new data must be read and Xlate-ed. In an edit table with all the data loaded, scrolling would at worst lead to paging of content to files, which is a fairly fast and simple operation. I believe.)

( Note that with my approach there is no paging of content. What I'm thinking of is: If my users do a lot of long jumps back and forth, the same chunks of display data would have to be generated (read and Xlate-ed) again and again. Then it could pay to save the content already generated. )

- Again - let's say I can get more than 64K of data into my edit table. But how much more? What if there are 50,000 hits, each with 40 Ks of display data? That's 2 megs altogether! Can an edit table really handle that much data?

- Oystein -

Øystein Reigem,

Humanities Information Technologies,

Allégt 27,

N-5007 Bergen,

Norway.

Tel: +47 55 58 32 42.

Fax: +47 55 58 94 70.

[email protected]

Home tel/fax: +47 56 14 06 11.

Today's listening suggestion: Bad Company (no, not that Bad Company): Inside the Machine (BC Recordings)

Oystein,

This is not a resolution for the sizes you are talking about, but it might sprout more of those idea germs.

If you are up to 4000 or so hits, you could Dimension an array with two 'columns' - up to 64k data in col 1 and Selected Flag in col 2.

You could then loop from n to n+100 (eg) and display that section, increasing n from the scroll bar, re-displaying the whole edit-table in one go, or just deleting first Row and Inserting bottom row (or vice versa).

Just a thought

Simon

Rebus

How about two edit tables, one you see, the other you don't?

Use table1 as a buffer. Load it in chunks on demand using row limit -1, then load visible window from the buffer, only 64 k at a time. Users pay price as they load, get speed when they scroll through already retrieved rows. You can have multi-select, though you will need to manage it with a hidden column in the buffer if you want to cross chunks.

hope this helps

Bob

Hi Oystein

I have been working on this myself. What I have done so far is to make an edit table which is fed by the contents of an editbox, since I was under the impression the edittable would only hold 32K of formatted data and the editbox could hold 64K of unformatted. Changing the row limit to -1 seems to link the amount of data that the edittable can hold to the amount of RAM the computer has, but I am probably wrong, and there is still a limit.

The only data entity that seems unlimited is the SLISTS or saved lists, and you can make savedlists and manipulate them yourself: something like list_id*1 list_id*2 list_id*3, but if you select and save the list this is done for you, and the activate list gives it back but not in a way that you can get a specific row back without readnext ing through the entire list. So I could use the SLIST as a base instead of the edit box perhaps.

What I did with the edittable and editbox (text box) was write a series of routines to page the data given a page row limit for the edit table (which I have let the user change), and page x of y field which I change programatically. Given x and y, the page row limit, the position in the edit table, I can look up the corresponding position in the edit box. I provide buttons to change pages, and using x, y and the row limit I can extract the next or previous page data as required. I made all this into function calls, or at least commuter proc subroutines. What a mess. It would be nice if the system, any paging system was incorporated into the OI platform.

A limitation I have at the moment, is that to actually edit a line on the page, or add, or delete, the user must click on an edit or new button, so the add/edit/delete of the new row is handled by the click event (via the commuter proc).

I could possibly work around this (allow editing directly in the table) by having saving an invisible old edit table on the got focus and comparing on the lost focus. I need to be able to validate changed lines against the rest of the lines so this adds to the complexity. But for a data display this isn't so much of a problem.

Happy to share details if you like.

Scott

working around for things I used to take for granted.

Thanks all for your responses.

Scott,

I have already solved the problem with accessing the right chunk out of the list's SYSLIST rows.

And there will be no chunks visible in my interface, just continuous scrolling.

Fortunately I don't want to change the edit table's data. Why on earth would anybody do that? (Just to provoke you into telling me what you need it for.) I'm just showing a result list. What I show is a set of lines representing real rows in a queried table. Even if I do show fields in addition to keys I won't allow users to edit the fields of the original rows. The only thing I want except browse is to be able to select rows - multiple rows, which also needs some extra programming. (Searching and sorting the content would be fine, but I don't see any solution the way I'm heading with this.)

- Oystein -

Hi Oystein

Reason want to edit table in rows, is similar to why you'd want to key data in an excel spreadsheet without having to deal with a form for each row. I could explain the purpose of my application in detail but I suspect the combination of computing jargon combined with accounting jargon (ie ledgers) would only act as a cure for insomnia. I've seen it have that effect before.

So a popup won't do for what you want?

I believe that you can make those sort by clicking on the column header, and you can allow selection of multiple rows and searches.

If only a popup could be combined with the edittable…

Scott

View this thread on the forum...