number of columns in a table field

Kay C Lan lan.kc.macmail at gmail.com
Thu Jun 1 10:04:38 EDT 2006


On 6/1/06, Bill Marriott <wjm at wjm.org> wrote:
>
> Kay C Lan wrote
> Ok, look at the instance where you want to add/insert one line. You have
> to
> push at least one line off-screen and write the new information in. If you
> are "paging" your screens it's not so bad. You can lock screen and it
> happens pretty quick.


Yes, which is exactly what I do.

But what if you want to allow smooth scrolling up and
> down, line-by-line?


My approach is definitely not 'smooth scrolling' - old data, blink, new
data. Left 10 columns of data, blink, Right 10 columns of data. I use
lockscreen all the time.


>  Not so bad when you are working with a fixed-sized display grid,
> but users really like to maximize their windows, display a lot of data,
> and
> whip the mouse around to different parts of the table.


I have the luxury of only having to worry about my own work preferences:-)

For all the shortcomings of the table object it's at least speedy to
> navigate. Using the
> on-screen-only approach would not be anywhere close to that.


Well I think this is a little along the line of ' 640K should be enough for
anyone'. I certainly felt I had to have 'tablelike' navigation until I
started working with really large amounts of data. I imagine loading a 8k
column x 500k row spreadsheet in Excel 2007 will not be a pleasant
experience:-)

Having discovered how to get my data to display immediately I've learnt to
live with the short comings of my stepped approach. I get the impression
(probably false) that I'm more productive because I don't have that initial
wait - but again this is only a factor for really large data sets.

The one-field-per-column approach works okay for fairly large numbers of
> rows. Scrolling up and down is handled by a loop which sets the scroll of
> visible columns and is fairly smooth. Scrolling side-to-side is handled by
> scrolling the group. But the problem with the approach is that the scroll
> gets wonky after a while of use; some users cannot scroll to the bottom
> when
> a large number of rows are present. And the horizontal scrollbar on the
> group is hard to tame. And of course, I have to loop through each column
> to
> write data instead of just blasting out a tab-delimited line, which is
> what
> I'd prefer to do.


I've starred this thread so that I can come back when I have a bit of time
to run a test stack with this approach:-) I'll probably start with only 6
columns, so I don't have to worry about horizontal scrolling:-)

Thanks for the extra info.



More information about the use-livecode mailing list