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 [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
