Copyright (C) 2000-2012 |
Manpages CONFIGSPECSSection: User Contributed Perl Documentation (1)Updated: 2000-05-21 Index Return to Main Contents NAMETk::ConfigSpecs - Defining behaviour of 'configure' for composite widgets.SYNOPSISsub Populate { my ($composite,$args) = @_; ... $composite->ConfigSpecs('-attribute' => [ where,dbName,dbClass,default ]); $composite->ConfigSpecs('-alias' => '-otherattribute'); $composite->ConfigSpecs('DEFAULT' => [ where ]); ... } $composite->configure(-attribute => value); DESCRIPTIONThe aim is to make the composite widget configure method look as much like a regular Tk widget's configure as possible. (See Tk::options for a description of this behaviour.) To enable this the attributes that the composite as a whole accepts needs to be defined.Defining the ConfigSpecs for a class.Typically a widget will have one or more calls like the following
$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 -option=>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:
Default ValuesWhen the Populate method returns ConfigDefault is called. This calls
$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 => valueis 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. New()-time ConfigureOnce control returns to new, the list of user-supplied options augmented by those from ConfigDefault are applied to the widget using the configure method below.Widgets are most flexible and most Tk-like if they handle the majority of their attributes this way. Configuring compositesOnce the above have occurred calls of the form:
$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 redirection 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. Inquiring attributes of composites$composite->cget( '-attribute' );This is handled by Tk::Derived::cget in a similar manner to configure. At present if where is a list of more than one object it is ignored completely and the ``cached'' value in
$composite->{Configure}{-attribute}.is returned. CAVEATSIt is the author's intention to port as many of the ``Tix'' composite widgets as make sense. The mechanism described above may have to evolve in order to make this possible, although now aliases are handled I think the above is sufficient.SEE ALSOTk::composite, Tk::options
Index
This document was created by man2html, using the manual pages. Time: 20:41:38 GMT, March 28, 2024 |