number of columns in a table field
ambassador at fourthworld.com
Thu Jun 1 13:32:42 CDT 2006
Bill Marriott wrote:
> You're saying that Rev's existing table object is just spiffy? Oh my, my
> ribs hurt from the laughter!
I hate to curtail a good chuckle, but that's not what I wrote. You
might have a simpler time with my posts by reading the full text of them
I wrote in agreement with your main point:
Sure, it could use enhancement. For example, a strong
nice-to-have is per-column alignment, and there's a
BZ request for that which I would imagine has the
attention of Rev's engineers.
I'll try to summarize my post for you as briefly as I can:
- I agree with you that list display can and should be enhanced in Rev.
- I disagree with the implication that it's a trivial effort to do so.
- Database products do not also provide general GUI application
development, multimedia support, rich Internet connectivity,
and the many other things that Rev is used for. Prioritization
in such a rich application is an ongoing challenge.
- There are many types of list and table objects, some more expensive
to build than others and they're not interchangeable. A spreadsheet
table is very different from a database table, which is different
again from an html-style table. They share some common elements,
but ultimately serve different purposes and require different
technical underpinnings. There is no "one size fits all" table;
FileMaker doesn't include a spreadsheet, Excel doesn't allow controls
in cells, and neither provides a tree view. Prioritization of these
very different needs is an ongoing challenge.
- I have no evidence that the folks at RunRev are completely ignorant
of these needs, and in fact we've heard comments to the contrary here,
at conferences, and elsewhere (though on balance I do agree with those
on this list who suggest that more participation here from RunRev
folks would be an invaluable confidence builder).
- Developers can assist prioritization through voting:
- Many developers are currently shipping highly profitable database
applications made with Rev as it is today.
- I'm building an app here which handles at least 50,000 records rather
gracefully, all in native Transcript (if you're coming to Monterey
for RevCon West you're welcome to heckle my session on "The Bionic
App" which will discuss this program and how its solutions lend
themselves to a wide range of common development challenges).
I'm not sure where the presumed limit of 2000 records came from,
unless you were merely returning the favor of a good laugh.
> Does the current "multi-column list" (i.e., glorified tab stops with
> borders) "prevent" database apps from being built in Rev? No, it just makes
> *quality* high-performance database presentation applications extremely (and
> needlessly) difficult to build!
If Rev isn't up to your application's requirements you might consider
downloading Visual Basic Express. I hear it's free.
VBA/Office is also an attractive multi-OS platform used for a wide range
of highly productive in-house applications.
And of course there's the many dozens of other products said to include
the sorts of tables you're looking for.
With so many choices available, it would be a shame to lock oneself into
using one tool to build everything.
Managing Editor, revJournal
Rev tips, tutorials and more: http://www.revJournal.com
More information about the use-livecode