number of columns in a table field

[Richard Gaskin]

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 
before replying.

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:
   <http://support.runrev.com/bugzilla/bugzilla.php>

- 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.

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com