Is this a bug?

[Richard Gaskin]

Chipp Walters wrote:

> Mark, your example also demonstrates the power of same named instances of
> object. I guess it all boils down to each of us trying our best to create
> reusable grouped components, each with the same codebase. A most difficult
> task.

In the absence of parentScripts (a shared library that is specific to 
assigned objects) I have yet to find an ideal solution, but here's a 
convention Ken and I tend to use for custom controls and other reusable 
groups, with three parts:

- a prefab template object
- an inspector for copying it and manipulating its properties
- a library to drive it

I have a table object that best exemplifies this arrangement.  The 
library stack also contains a group which is coped by the inspector onto 
the card to create a new one.

The template object has almost no code; where needed it has stub 
handlers that just make calls to the library.  For example, the column 
resizing controls simply contain mousedown, mouseMove, mouseUp, and 
mouseRelease handlers which call _lib4wTableHeaderMouseDown, 
_lib4wTableHeaderMouseMove, _lib4wTableHeaderMouseUp, and 
_lib4wTableHeaderMouseRelease messages, respectively.

Note the preceding underscore.  That distinguishes handlers in the 
library which are used internally only, as opposed to those which are 
part of the API (when we get truly private handlers that convention can 
go away).

Most of the object's behaviors are established as property settings. 
For example, setting the ufwTableData of the group puts the specified 
columnar data into the table; setting the ufwTableHeaderInfo of the 
control sets up the column heading labels and widths; setting the 
ufwTableSortColumn of the group establishes which column the data is 
currently sorted by, and colors that heading differently from the others 
as per the OS HIG.

These property settings are handled in getProp/setProp handlers in the 
library.  They keep track of the target object, so any number of tables 
can be used in a layout without conflict.


Having as much code as possible in the library means I never need to 
update any controls to enhance functionality.

Having a template object means all instances get implemented 
consistently with reasonable default settings.

Having an inspector means I get to install tables and modify their 
settings quickly without having to write a line of code.


If I get some time I'll publish my table widget, but with my current 
workload it's hard to say exactly when that'll be....

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com