CLIM mail archive
Re: Spreadsheet style input method (or AVV)
Subject: Re: Spreadsheet style input method (or AVV)
From: Nichael Cramer <ncramer@BBN.COM>
Date: Wed, 26 Jan 94 8:39:35 EST
>Date: Tue, 25 Jan 94 17:00:10 EST
>From: Mike Harper <mlh@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,
(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"
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
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
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. ;-)
Main Index |