--- Richard Gaskin <[EMAIL PROTECTED]> 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 _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
