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
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
