CLIM mail archive
[Prev][Next][Index][Thread]

Re: Spreadsheet style input method (or AVV)

>Date: Tue, 25 Jan 94 17:00:10 EST
>From: Mike Harper <mlh@BBN.COM>
>To: clim@BBN.COM
>Subject: Spreadsheet style input method (or AVV)
>
>Has anyone built some type of spreadsheet like data input system in
>CLIM (1 or 2)? Is this even a reasonable style of input to use CLIM for?
>  
>  Mike Harper
>  Alcoa Laboratories

I've been working on a spreadsheet/table-editor system for some time (the
original version was in CLIM-0.9; it currently works under 2.0).

I don't know the actual status of "releasing" it (for example, putting it
in the CLIM library) but I can certainly discuss some of its features.

1] As mentioned before the straightforward "incremental update" model is
*far* too slow to manage a table of any size at all.  (For example one
application typically displayed tables that were as large as 30X1000
cells.)  Consequently I needed to build a redisplay system built on an
underlying grid of cells which, among other things, displays only what is
on the screen at a given time.  (A lot of this made easier by the fact that
none of the cells overlap; as a result redrawing an individual cell is much
simpler, I don't have to worry about refreshing other overlapped cells,
etc.)

(As I say, this was originally written 'way back in 0.9 days, i.e. before
things like Scott's grid-output-record tool.  I may looking into merging
this, but so far I haven't had time.)

2] The presentation of the cell consists of 1] the presentation of the
value in the cell (e.g. the number, string, etc.) and 2] the presentation
of the surrounding cell object.  In this way, by defining the appropriate
presentation types and commands, the "cell-like" operations can be kept
separate from the "value-like" operations.

3] Editing (via ACCEPT, of course) is typically done in a seperate "input"
window.

4] Most scrolling is handled by hand to facilitate parallel scrolling of
adjacent windows (for example row- and column-header panes need to scroll
in synchrony with the "main" table pane, while being in seperate windows so
the header information doesn't scroll-off).

5] I built a special "sub-frame-like" pane to support clustering sets of
window in a consistent and reproducible way.  (This is similar to the old
SMBX/Dynamic Windows notion of allowing a frame to be included as pane in
another frame).

For example, as described above, a simple table-editor typically consists
of a main pane, row- and column-header panes, an input-pane and two
scroll-bar panes.  Some applications have required two or more tables to be
included in a single frame.  In this case it is useful to define a
table-editor "sub-frame" and use multiple copies of those rather than
declaring all of the individual panes seperately in the top-level :PANES
form.

6] The features described above deal primarily with the underlying display
issues.  Higher level commands are properly moved up to the particular
table-editor class.  For example spread-sheet-like operations --summing a
column into a particular cell, sequential editing of cells, and so on-- are
features of a spread-sheet application.  On the other hand an array-editor
would required a rather different set of operations while still being based
on the same underlying display technology.

7] Finally, wrt a question implicit in your "Subject" line, this system is
designed to be a seperate self-contained display; i.e. it's not something
that would be included into, say, an AVV window.  Jeff Morrill has
suggested looking into trying to turn some subset of this into an
"array-view", but nothing has come of this (yet).


Anyway, I hope this isn't too much hand-waving; it'd make a lot more sense
if I could just sit down and show it to you.  ;-)

Nichael
Main Index | Thread Index