number of columns in a table field

[Jonathan Lynch]

my psuedo-table object works pretty well - Marielle made it available on his
site. It addresses many of these concerns.

However, I would not use it for thousands of rows. For a couple hundred
rows, it works ok, but for 2 or 3 thousand rows - well, that is just too
many sub groups for the engine to handle quickly.


On 5/31/06, Bill Marriott <wjm at wjm.org> wrote:
>
> 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.
>
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>