Table inspector from 4W

[Richard Gaskin]

-= JB =- wrote:
 > Each cell can already be controlled separately plus have its own font
 > & style.  The columns can already be resized but the rows still
 > need to be able to be resized.  The data can be stored how they are
 > storing it now and if needed changed in the future.  There are
 > already examples that show how to resize and move fields.  Columns
 > can automatically be resized too.  Each cell can easily become as
 > many separate  buttons as the programmers wants.
 > Searching and sorting can easily be incorporated.  Locking text is
 > already a standard too.
 >
 > Many things can be done very fast because it is already being done.

Where?


 > After they release a sophisticated flexible table field users can
 > make suggestions for more features.
 >
 > If it is too hard for them then Richard should continue improving his
 > field.  If they have intentions of changing it soon they should tell
 > him so he won't waste his time.  He gives a lot of his time already
 > and considering the amount of time he has given they owe it to
 > him to not treat him like a mushroom and keep him in the dark.

I appreciate the kind words.  Actually, before I started down this road 
I did check in with Kevin, and he told me it would be at least a year 
before RunRev provided any sort of header controls such as I was making. 
  That was more than a year ago, so the time spent on my little gadget 
has been useful.

If it were up to me, I would prioritize enhancements related to this 
with these two leading the pack because they're relatively simple and 
are oh so needed:

1. Independently resizable columns

2. Hidden columns

Those two would provide a significant step forward for most database 
work people are doing right now.  I would prioritize them above all 
else, esp. ahead of things I've heard very few ask for, like 
finely-tunable gradients.

Once those are in place, I would move forward with:

3. Decimal alignment in columns

4. Built-in header controls

5. Built-in option for in-cell editing

6. Built-in alternating line backgrounds

7. Update the threeDHilite for a rounded, more modern appearance

8. Allow multi-line cells

9. Allow controls in cells

These, coupled with the features in the current field object, that would 
suffice most of what people would need for list selectors.

Once the list selector is completely done, only then would I consider 
making a spreadsheet-style grid control.  Spreadsheet grids are very 
different from lists, much more complex and for a much smaller range of 
uses.

In fact, given the cost-to-benefit ratio of spreadsheet grids, I might 
go a completely different route to solving that, by not solving it at all:

Instead, I'd make an API for externally-defined controls, and worth with 
third parties to use that API to make widgets for vertical needs like 
spreadsheets, calendars, and just about anything else they can dream up.

Think altBrowser, but tightly coupled with the engine's rendering and 
messaging internals.

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com