table calculations

Jan Schenkel janschenkel at yahoo.com
Fri Jun 6 00:40:01 EDT 2003


--- Richard Gaskin <ambassador at fourthworld.com> wrote:
> Graham wrote:
> 
> > Jan, it's crystal clear to me that you understand
> what **is** on offer in
> > RunRev tables about 100 times more clearly than I
> do. I realise that
> > autoformatting of cells is offered in some form,
> but I can't work out the
> > consequences of errors (how does my script know
> the user has put in a
> > random text instead of a date, for example?). And
> in what sense are tables
> > hooked up to queries - indeed, what is a query in
> this context?
> > 
> > What beats me is how you reached your level of
> understanding from the
> > existing documentation. I feel dumb. I will go
> back to experimentation, but
> > it seems long and slow to me.
> > 
> > Just tell me there is a great little essay on how
> tables work, and I've
> > missed it. I'd be really happy.
> 
> At the heart of this may be that the definition of
> "table" varies from
> person to person.  For some it means a database list
> view, while for others
> it may mean a spreadsheet.
> 
> Unfortunately, all the two have in common is that
> grid lines appear in each
> -- behaviorally they are very different:
> 
> -  Databases select by row, spreadsheets select by
> cell.
> 
> - Databases normally only edit in a detail view,
> while spreadsheets edit in
> place.  
> 
> - Database heading names are commonly field names,
> while spreadsheet
> headings are commonly generic (most using alphabetic
> characters).
> 
> - Databases usually have one size for all rows,
> while most spreadsheets
> allow each row to be sized independently.
> 
> - Databases follow a rigid row-and-column format,
> while spreadsheets are
> very free-form, allowing data in any arbitrary cell.
> 
> Rev's implementation seems geared toward database
> usage, with the extra
> bonus of allowing in-cell editing.  So while there's
> probably some
> opportunity for Jeanne to expand the docs on this
> new feature as she catches
> up on the rest of this very large IDE (she's still
> ahead of both the teams
> at Adobe and Macromedia for overall completeness,
> IMNSHO), it seems part of
> the confusion about using tables seems related to
> expectations of which type
> of table they are.
> 
> -- 
>  Richard Gaskin 
> 

Hi Richard,

You hit the nail on the head : different needs create
different expectations.
While some things would be best handled by a native
table object at engine level, a bit more interaction
with the revTable functionality in the next version
would be a god-sent and alleviate some of the
perceived low-points :
- a message to warn us of a cell change as well as our
ability to invoke one
- the ability to hook up our own formatting function
in addition to the standard ones and a way to trap
those when I'd rather see a decimal comma and/or
thousand separators
- the ability to hook up our own input-checking when
that functionality is added
- max rows and columns count
- setProp + getProp to access data of individual cells
rather than having to kludge around if you don't want
to see the data overwritten

What I know about tables is what I learned from the
sporadic (but very informative) messages on the lists,
and by digging around in the revTable frontScript.
A good essay on what it can and cannot do would
certainly help a lot.

My 2 euro-cents.

Jan Schenkel.

=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com



More information about the use-livecode mailing list