number of columns in a table field

[Bill Marriott]

Kay,

Sorry, I'm not sure what you're talking about -- of course all those UI 
options are great but the way one must use them is not. The standard method, 
I believe, is to use a group the hold all those fields and controls, and 
then scroll that group around. But the performance of such a solution is 
truly awful when you have to move around hundreds of rows of a couple dozen 
columns. Not to mention that the Geometry Munger likes to resize the group 
when it feels like it, and group scroll bars -- horizontal and vertical --  
like to resize themselves at will. You end up rolling your own geometry 
manager and scrolling manager and resize manager, etc. I do not think it is 
fun to build all these things from scratch, especially when I want to have 
some advanced options like splitters and discontinuous selections, proper 
cross-platform handling of keyboard controls, response to scroll wheels, 
etc., etc. There are various sample stacks out there that try to address the 
shortcomings of the built-in table object, but none of them are perfect... 
which just shows you how hard it is to do.

Even rolling my own, I had one standalone where people couldn't scroll to 
the very bottom of a group after a certain number of rows were used. And to 
fix it I had to completely delete everything and rebuild from scratch. It 
wasn't my code; Rev simply "held on" to something deep in its bowels and 
wouldn't let go of it. Groups like to make themselves a couple pixels off 
the size of the selected objects so you have a very unprofessional-looking 
appearance. More than once I had scrollbar thumbs that refused to move all 
the way to the beginning or end of their range. If you're not careful during 
development you can force the group's size to reset and it's difficult to 
realign it just right. I don't like having to spend 60% - 70% of my 
development time "reinventing the wheel" and working around display 
idiosyncrasies just to get a decent grid UI. That is not "software at the 
speed of thought" or "rapid application development" by any stretch.

The basic table object can't right-justify or center-justify columns, easily 
lock column and row headings, or even apply its own number formatting rules 
automatically. If a user tries to edit a cell, they get an edit box that is 
much larger than the size of the cell being edited. If you try to edit the 
right-most  visible column of a table, Rev forces horizontal scrolling and 
the addition of an extra column. Using the built-in, undocumented, set and 
get cell commands is slower than molasses; but if you don't use those 
methods the contents of the field disappear when you make changes (like 
resizing the field) during development. You can't easily select columns of 
data, and you can't embed radio buttons, check boxes, or drop-down lists. 
This is in sharp contrast to what one can do in FileMaker, Excel, Visual 
Basic, and most other development environments I can think of.

I am not making this stuff up, much of it is already documented in BugZilla.

In short, the Revolution table object is crap and the alternatives are 
exercises in frustration. In my opinion ... Attention to *QUALITY* grid 
handling is an absolute necessity for the next major update if Rev wants to 
be taken seriously for database work.

Kay C Lan wrote
> Whilst Table representation certainly has its advantages and place, I
> think if you look a little deeper into a 'customised' display you'll
> be quickly impressed with the power and flexibility it provides.