number of columns in a table field

[Bill Marriott]

Richard Gaskin wrote:
> 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.

This is definitely the pot calling the kettle black.

> - I agree with you that list display can and should be enhanced in Rev.

Good. Maybe we can leave it at that.

> - I disagree with the implication that it's a trivial effort to do so.

Better for Rev to provide such an object in highly-optimized C++ than for 
hundreds of customers to try and emulate it in Transcript. Sure it's not 
trivial -- I never implied it was. But that's why we pay for the product.

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

If I compare to applications, you cite scripting environments. If I compare 
to development environments you bring up applications. What kind of market 
segment comparison will you stick to?

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

You certainly can add check boxes, drop down menus, and other controls to 
Excel cells. But that's beside the point.

I selected an integrated development environment (VB Express) and detailed 
several specific facilities their general-purpose data grid control provided 
that make it a breeze to present data. That is certainly enough for me, 
light-years ahead of what Rev offers, and proved your point about there 
being a dearth of such controls to be false.

The claim that one can't offer a decent data grid because we can't decide 
whether to make it a database, a spreadsheet, a web page, or a tree control 
just obfuscates what really is a straightforward issue. You almost make it 
sound like a decent data grid is somehow incompatible with what Revolution 
is about.

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

Well that is good. And I suspect their reluctance to document what does 
exist also shows in a backhand way their intention to change it, someday. 
Been a few years now. But someday.

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

Amen to that.

> - 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 about to criticize anyone who has gone through the pain of rolling 
their own solution. My point is they shouldn't have to. I hope people do 
take the time to vote for the table-related items in BugZilla. But filling 
out a proper report takes time and the overall participation in BugZilla by 
end users strikes me as quite anemic. The discussions on this list should be 
factored in as well.

>   I'm not sure where the presumed limit of 2000 records came from,
>   unless you were merely returning the favor of a good laugh.

It came from your earlier post, a very good one, where you learned:

"What I found is that the number shown above assigned to N is the max I
can create here without odd positioning of objects.  If I exceed that I
start getting row groups positioned over other row groups."

Your value for N was 2113.

> If Rev isn't up to your application's requirements you might consider 
> downloading Visual Basic Express. I hear it's free.

Since I mentioned that VBX was free in my post you're either guilty of not 
reading it completely before replying (see "pot calling kettle black," 
above) or being extra cheeky. Love the dry humor!

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

There's so many subtle layers to that last section it's hard to decide where 
to begin.

I guess the first thought is, do you tell a C++ programmer that they've 
"locked themselves in?" Perhaps so. I'm sure a lot of guys lost their jobs 
because a company shifted from classic applications to web-based systems, 
and needed JavaScript not C++. On the other hand, is it more marketable to 
know a lot of languages sort-of-okay or a couple languages intimately? To 
mangle an aphorism, "you can program in all the languages some of the time, 
and some of the languages all of the time, but you can't program in all 
languages all the time."

Each new project presents of choice of what tool to use, and each day brings 
the question of whether to invest one more hour of time into what you 
already know (to move from say, intermediate to advanced) vs. what you don't 
know. Knowing what I know about the alternatives, do I continue to struggle 
making tables the way I want in Rev, or do I dump the whole project and 
tackle Visual Basic? Are you saying it's not a wise decision to invest too 
much in Revolution?

The second thought... It is indeed a shame that we don't have a wide variety 
of HyperTalk/Transcript/XTalk implementations to choose from. Some 
competition would be very healthy. And it certainly is true that the 
capabilities of these alternative environments make them increasingly 
attractive to people who wish to build robust applications. But as someone 
who loves the language, knows the language well, and generally admires 
Revolution, it is extremely frustrating we have not seen progress on the 
table object in some time.

The final thought is... Sound concept to use the right tool for the right 
job. The more tools in your repertoire, the better. And I certainly don't 
use Revolution for everything, personally.... not even 25% I would say. But 
it sad to see the universe of things I *would* consider doing in Rev 
dwindling.

I hope you'll not only continue showing people how to make the most of what 
Rev does offer with your publication and presentations, but also use your 
influence to call a "spade a spade" and champion much-needed enhancements to 
the product.