Yes, custom objects need some Tcl code too.
Take a look at csphere.tcl. This Tcl code creates a single procedure that, in turn, creates the Property GUI of the CSphereAttribute property. The code is really simple and creates a static GUI consisting of a label and four entries for parameters. The procedure will be executed whenever the user tries to manipulate the CSphereAttribute property of a csphere custom object.
What means static in this context? Static means that the property GUI will not be rebuild (read, the procedure csphere_buildCSphereAttrGUI will not be called) on every apply operation of the user. The default behaviour of property GUI's is, that they are rebuilt for every apply operation, this allows for really dynamic GUI's to be generated.
Now on to the other procedure calls.
A property GUI is usually organized in list form. The single list elements are mostly built by calling a single Tcl command of the Mops core. A list element of a property GUI is referred to as entry from now on.
The template for such a command (that creates a single line of a property GUI) is as follows:
add$typeEntry $w $array $name
Type is the type of the entry. Predefined and heavily used by the rest of The Mops are: Text, Param, Menu, Check, Color, File, String and Command. Depending on the type, the actual parameters are a bit different but this is documented in detail later on...
$w
is the window the new entry should be created in.
Since the create property GUI procedure will be called with
this information as argument, passing it on to the create entry
procedure is the logical consequence and simple to do.
$array
is the name of the (global) array where
the parameters that should be edited are actually stored.
$name
is the name of the variable in the global
array $array
that this entry should manipulate.
In addition, this name is often used in a label to mark
the entry. You should use descriptive and not too
long variable names.
You are, of course, not tied to the aforementioned entries. The seashell custom object, for instance, implements an own type, an entry consisting of a slider, that is even able to issue apply operations while dragging the slider. However, how to program your own type of entry is not documented yet, UTSL!
Here is now the documentation for all core entry types:
addTextEntry $w $f $text
adds a line containing the text $text
to the property GUI.
$f
is required to generate window names, use e1
,
e2
etc.
addParamEntry $w $array $name
creates the standard parameter manipulation entry consisting of a label, two buttons for quick parameter manipulation by doubling, dividing the value, and finally an entry for direct manipulation.
addMenuEntry $w $array $name $list
adds a menu button, that toggles between the elements
of the list $list
. The variable $name
always contains the index of the selected entry.
addCheckEntry $w $array $name
adds a single check button to the GUI. The variable $name
will be set to either 0 or 1 according to the state of the check button.
addColorEntry $w $array $name
adds a color selection facility. The color values will be
written to variables named ${name}_R
, ${name}_G
,
${name}_B
and ${name}_A
.
addFileEntry $w $array $name
adds a string entry and a small button, that starts the standard file requester, handy for strings that contain file names.
addStringEntry $w $array $name
adds a simple string entry.
addCommandEntry $w $f $text $command
adds a big button labelled with $text
that starts
the command $command
.
$f
is similar to text entries a name for a window,
I suggest to name the windows c1
, c2
etc.
You may link additional functionality of your custom object to entries in the custom menu.
The following example code snippet shows how to do that.
global prefs $prefs(cm) add cascade -menu $prefs(cm).foo -label "Foo" set m [menu $prefs(cm).foo] $m add command -label "Foo(l)" -command fooproc
Note, that you should always create a new submenu using a cascade entry instead of creating entries directly in the custom menu.