sub Populate { my ($composite,$args) = @_; .... $composite->ConfigSpecs(-attribute => [ where, dbName, dbClass, default ]); $composite->ConfigSpecs(-alias => '-otherattribute'); $composite->ConfigSpecs( DEFAULT => [ where ]); .... } $composite->configure( -attribute => value );
$composite->ConfigSpecs(-attribute => [ where, dbName, dbClass, default ]);
in its Populate method. When ConfigSpecs is called this way
(with arguments) the arguments are used to construct or augment/replace
a hash table for the widget.
(More than one key => value pair can be specified to a single call.)
dbName, dbClass and default are only used by ConfigDefault described below, or to respond to 'inquiry' configure commands.
It may be either one of the values below, or a list of such values enclosed in [ ].
The currently permitted values of where are:
This form is also a useful placeholder for attributes which you currently only handle at create time. IP "'CALLBACK'" 4 Setting the attribute does Tk::Callback->new\|($value) before storing in $composite->{Configure}{-attribute}. This is appropriate for -command => ... attributes that are handled by the composite and not forwarded to a subwidget. (e.g. Tk::Tiler has -yscrollcommand to allow it to have scrollbar attached.)
This may be the first of several 'validating' keywords (e.g. font, cursor, anchor etc.) that core Tk makes special for C code.
This is the most general case. Simply have a method of the composite class with the same name as the attribute. The method may do any validation and have whatever side-effects you like. (It is probably worth 'queueing' using afterIdle for more complex side-effects.)
A common case is where $reference is a subwidget.
$reference may also be result of
Tk::Config->new(setmethod,getmethod,args,...)
Tk::Config class is used to implement all the above keyword types.
The class has 'configure' and 'cget' methods so allows higher level
code to always just call one of those methods on an 'object' of some
kind.
While this is here for backward compatibility with Tk-b5, it is probably better just to use the subwidget reference directly. The only case for retaining this form is to allow an additional layer of abstraction - perhaps having a 'current' subwidget - this is unproven.
$composite->ConfigSpecs;
(with no arguments) to return a reference to a hash. Entries in the
hash take the form:
'-attribute' => [ where, dbName, dbClass, default ]
ConfigDefault ignores 'where' completely (and also the DEFAULT entry)
and checks the 'options' database on the widget's behalf,
and if an entry is present matching dbName/dbClass
-attribute => value
is added to the list of options that new will eventually apply
to the widget. Likewise if there is not a match and default is defined
this default value will be added.
Alias entries in the hash are used to convert user-specified values for the alias into values for the real attribute.
Widgets are most flexible and most Tk-like if they handle the majority of their attributes this way.
$composite->configure( -attribute => value );
should behave like any other widget as far as end-user
code is concerned.
configure will be handled by Tk::Derived::configure as follows:
$composite->ConfigSpecs;
is called (with no arguments) to return a reference to a hash
-attribute is looked up in this hash, if -attribute is not
present in the hash then 'DEFAULT' is looked for instead.
(Aliases are tried as well and cause re-direction to the aliased attribute.)
The result should be a reference to a list like :
[ where, dbName, dbClass, default ]
at this stage only 'where' is of interest, it maps to a list of
object references (maybe only one) foreach one
$object->configure( -attribute => value );
is evaled.
is returned.