I wrote what I think could be the docs for the start of a consistent interface. They are only 4 methods, all refered to creation and disposal of tables. I think that there is a clear user model, and that with these four calls, a powerful use of the system is possible. What do you think?

(Thanks again Iñigo)

I opened a discussion related to the document.

---

#axPrepareTable, tableName, columnWidths, lContent, styleName, callBackObject, targetRect

Builds a table up, but doesn´t draw it yet. The process is asynchronous, so building large tables can be done in background. Returns a “mTablePrepared”event to callBackObject (if available) when ready. 

Returns: tableName or error code

Parameters:

tableName: name for the table, useful to refer to it later. If the name has already been used on a“live”(not disposed of) table, the script will return an error. If a new name is used, the table will draw in its own rect, next to any table already drawn.

type: #symbol or #string

default: “table” & sequential index number

columnWidths: define the widths for the columns. Default: #equal

Possible types are:

#integer: defines a unique width for every column.

#symbol: defines how to calculate the widths; possible values are:

#equal: distribute available width (defined in targetRect)

#adaptToContent: variable width based on content.

#useMaxLength: calculates the max width and uses it for all the columns.

#list: defines every column in the table. Possible values for the items are:

#integer: absolute width for each column.

Example: [30, 45, 30, 45]

#float between 0 and 1: define the proportion of the column.

Example: [.3, .2, .2, .3]

#list of float (as previous) and alignment symbol.

Example: [[0.08, #right], [0.23, #left], [0.07, #right], [0.12,

#right], [0.1, #left], [0.12, #right], [0.12, #right], [0.16, #right]]

lContent: list of lists (rows) of lists (cells). These cells define the content of the table, can be of different types and can have a large number of properties. (see docs). Possible types for cells are:

#string: text that can be static or dynamic, based on properties defined in styleName.

 (Alex, you could add a couple new props to the defaultTableProps: #treatStringsAs (#static, #image, #editable, #button…), and #treatImagesAs …mmm, that is not too flexible, is it?)

#image: Again define how to use it in styleName.

#propList: for greater control, define every parameter this way. The most important property is:

#myContent: obligatory, must be a #string or #image.

(see docs for the rest, that are optional)

styleName: name of the CSS definition script (see docs).

Type: #string

Default: “default???”

callBackObject: Object to send the outgoing calls to. It will not give an error if the handler does not exist. (see calls in docs).

Type: #object

Default: send movie level calls.

targetRect: rect to draw the table in.

Default: the rect of the host sprite.

a) #axShowTable, tableName, columnWidths, lContent, styleName, callBackObject, targetRect

b) #axShowTable, tableName

Draws the table right away, using the transition and other parameters defined in styleName . Two parameter options:

a) Same parameters as #mPrepareTable

b) Only the name if the table was prepared beforehand (using #mPrepareTable). 

Returns: tableName or error code

#axHideTable, tableName, fKillTable

Hides the table using the established transition (see styleName). If flag fKillTable is TRUE, will call axKillTable when transition finishes. If is FALSE or void, the table can be recalled using #axShowTable (tableName).

#axKillTable, tableName

Completely destroys the table and releases resources. It does not execute the established transition.