Table Fields

Richard Gaskin ambassador at fourthworld.com
Fri Apr 18 11:49:43 EDT 2008


viktoras wrote:
 > I think given enough motivation (stress, fun, money ;-) ) someone
 > should be able to create such a perfect "generic" standard reusable
 > table object using combination of existing text fields and other
 > objects in rev. And I know a few examples that can be reused.
 > Nevertheless, for most tasks gridded text field with a few
 > scripts is more than sufficient (displaying database contents,
 > calculations, etc...)...

The difficulty in creating a one-size-fits-all table is that there are 
at least three different types:

- grid editor:  the type seen in spreadsheets; allows in-cell
   editing, has row and column selection controls on left and
   top respectively, allows single cells to be selected, and
   allows regions of cells, even discontiguous ones, to be
   selected.

- list selector:  most commonly seen in databases; selects
   whole lines (records) rather than single cells, may or may
   not allow in-cell editing.

- html table: for displaying text; allows multiple lines per
   cell, can display any control in a cell; provides selection
   of text rather than cells or rows.

It may be possible to create a single table object in the engine which 
adopts these different behaviors based on a style property, but if 
building one based on the current objects available it may be best to 
build them separately, since each would be constructed using very 
different means.

There are a number of requests for various enhancements related to 
grids, worth voting for if you haven't already:

add html table functionality to fields
<http://quality.runrev.com/qacenter/show_bug.cgi?id=1447>

More complete tables (actual grid control)
<http://quality.runrev.com/qacenter/show_bug.cgi?id=670>

Addition of "column" and "row" as chunk types
<http://quality.runrev.com/qacenter/show_bug.cgi?id=4623>

Zero-width columns
<http://quality.runrev.com/qacenter/show_bug.cgi?id=5947>

Add tabAlign property for fields
<http://quality.runrev.com/qacenter/show_bug.cgi?id=2282>



 > However, a few default features that would be nice to have in those
 > text fields would be possibility to resize the cells by dragging
 > vertical gridlines with mouse. This is based on feedback from my
 > own clients - they usually ask why in my apps they can not contract
 > or expand table collumns by dragging column borders with mouse, or
 > make cell resize to match its contents on left-doubleclick...

I've been working off-and-on for quite some time on a database selector 
type of table object - here's a snapshot of the latest version in action:

<http://www.fourthworldlabs.com/table.jpg>

It's columns are resizable as you describe, except for the double-click 
to resize to match the formattedwidth of the column.  That's a good 
feature I can add soon.

It doesn't currently provide in-cell editing, since the project I'm 
using it in right now is essentially a database and only needs a 
selector.  I may have another project coming up in which in-cell editing 
may be useful, and if so I may add that.

My original goal was to release it as a product for a modest licensing 
fee as Malte has done with his wonderful animation library, but the 
table needs of other developers here vary so broadly that I haven't yet 
decided if it's worth the effort to document it and clean up the API to 
make it suitable as a product.

Like Steven McConnell says, "With a tool it need only be possible to use 
it correctly, but with a product it should be impossible to use it 
incorrectly." :)  The difference between the two is about an order of 
magnitude more work, and the nice thing about it not being a product is 
that I can manage expectations easily without pressure, since I'm the 
only customer.

That said, it would be nice to know if this gadget would be useful to 
others, with a licensing fee of something like $50 for commercial use 
and free for use in non-commercial projects.  I could even price it 
higher if people insist. :)

If so, please drop me a note offline and let me know, and that'll help 
me gauge what level of effort I should put into this.


 > I know this is possible to script, however, somehow did not try yet
 > to create such a useful script myself :-).

Can't say I blame you.  Getting column resizing to work as well as 
iTunes is a lot of mind-bending work, especially if the table allows 
horizontal scrolling as iTunes does.  Mine's not yet quite perfect, but 
getting it even close was a lot of work across more than a dozen 
revisions.  So many ways to skin cats.....


 > Also cell addressing with commands like "answer the cell A3 of
 > fld myTable" or "get the cells A1:B10 of fld myTable"  or "put
 > the cells A1:Z1 of field myTable into fld myHeader" would be
 > very useful for any text field, not just tables... Any recipes?..

You could write a function for that, something like:

-- GridContents
-- Returns the contents of the field specified by a long ID
-- in pTableObjectILongID, according to the specification in
-- pCellSpecifier.
--
-- pCellSpecifier uses spreadsheet conventions, where a selection
-- is either a single cell with row specified by a letter and
-- column specified by as number (e.g., "A10"), or a pair of
-- such specifiers denoting a range, separated by a colon
-- (e.g., "A1:B16").
--
function  GridContents pTableObjectILongID, pCellSpecifier

The hard part is parsing the alphabetic portion of pCellSpecifier; not 
impossible, but tedious to script.  And unless one had spreadsheet-like 
row and column header controls denoting the cell locations on screen, 
the usefulness of such a function would be very limited.

Using numbers rather than letters would reduce the tedium in writing the 
script, allowing specifiers like "1,1:2,10" for what would in 
spreadsheet-talk be "A1:B10".  If numeric row specifiers were acceptable 
it would be fairly simple to script, a la:

on mouseUp
   put GridContents(the long id of fld "fwTableField", "1,2:2,8")
end mouseUp


function  GridContents pTableObjectILongID, pCellSpecifier
   put the text of pTableObjectILongID into tData
   -- Parse the specifier:
   set the linedel to ":"
   put item 1 of line 1 of pCellSpecifier into tStartRow
   put item 2 of line 1 of pCellSpecifier into tStartCol
   put item 1 of line 2 of pCellSpecifier into tEndRow
   put item 2 of line 2 of pCellSpecifier into tEndCol
   --
   set the linedel to cr
   set the itemdel to tab
   if tEndRow is empty then
     -- Single cell in specifier:
     return item tStartCol of line tStartRow of tData
     --
   else
     -- Range in specifier:
     --
     -- Get only the rows of interest:
     put line tStartRow to tEndRow of tData into tData
     -- Step through them to extract the columns:
     put empty into tNuData
     repeat for each line tLine in tData
       put item tStartCol to tEndCol of tLine &cr after tNuData
     end repeat
     delete last char of tNuData -- trailing cr
     --
     return tNuData
   end if
end GridContents



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



More information about the use-livecode mailing list