number of columns in a table field
wjm at wjm.org
Thu Jun 1 15:11:30 CDT 2006
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
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
> - 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:
> - 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
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,
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
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
More information about the use-livecode