Table Field features (for v2.5)

Barry Levine themacguy at macosx.com
Thu Aug 26 16:04:06 EDT 2004


Just played with the table field (and locked up the beta when tabbing out of
the second column or "return"ing out of the second row).

Reviewing the commentary about the requested feature set for this object, I
can only point to RB's implementation as what I want. Head over to the RB
website to see this.

The number of columns and rows are user-defined so no "extras" are seen
hanging over from outside the object's rect (partially scrolled out of view,
so to speak). With a small amount of code (about 12 lines), support for
"returns" and "tabs" selects the content of the next cell (down or across,
respectively) and wraps around in a logical manner (to the next row or
column, respectively).

There is code within RB to populate such a list from a database. Rev, also,
has such code.

But we should not zero in on this table field as only having a use with
databases! Rev's stack-of-cards metaphor permits this object to be quite
useful for a number of purposes beyond a vessel for SQL retrieval.

Let's consider what might happen when a user tabs into the cell; perhaps it
triggers a handler to bring up a choice list (like  FileMaker or Access). I
realize that feature is a big jump from a simple "block of editable cells"
so I won't request this for v2.5 (maybe 3.5). However, causing a drop-down
list or popup menu or even a little modal dialog to appear at the
appropriate location is do-able given the current (stable release) state of
Rev.

What about when a user clicks on (or keyboards into) a cell (whether its
contents are editable or not). Such an event ("on activate x,y" where x,y
indicates the cell) could be the trigger for spreadsheet-like calculations
(with the existing math functions and "plain old Transcript" handlers;
nothing new required for this). Example: Enter "1000" into a cell, tab out
of it, and the adjacent cell gets a new value based upon some handler.
Asssuming this cell is not editable (by setting a property in an openCard
handler presumably), a "tab" would skip over this cell and activate the next
(in the "tab" order or whatever we set in a handler or property). Again, I'm
not calling for this object to handle hidden formulae (like Excel) so that
only the value is displayed; do we really need another Excel or AppleWorks?

What I had to do in HyperCard (in 1988) to emulate a multi-column edit field
was to line up as many list fields as I required but I could not permit the
user to enter any data in the fields; rather, I had to intercept the
mouseClick and present a dialog in which the user could enter the data for
each cell. I was finally able to improve the interface to a larger dialog
which would permit "a row at a time" worth of data. Haven't we progessed in
16 years? Well, considering the v2.5 Rev beta, it looks like we're getting
there.

So I really hope people won't look at this posting as a diatribe nor as a
series of complaints; rather, this is a list of suggestions. It is entirely
possible that 2.5beta has the "on activate" type of handler for a cell but I
haven't been able to get much out of this object in the beta yet.

Regards,
Barry




More information about the use-livecode mailing list