Table Fields
Robert Sneidar
slylabs13 at mac.com
Fri Apr 18 18:14:32 EDT 2008
Hi Richard.
This looks like a very usable table object in it's own right. While I
would like editing in cells at some point, my specific needs would be
to present the user with a list of records, from which they could
double click one so I could present them with a detail record to work
with. The nice thing about your table object is it LOOKS like a table.
I would pay good money for such a tool, for personal use or otherwise.
Bob "SlimPikn" Sneidar
Hog Pilot Extraordinaire
On Apr 18, 2008, at 8:49 AM, Richard Gaskin wrote:
> 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
> _______________________________________________
> 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
More information about the use-livecode
mailing list