1.5 Argument Lists

1.5.1 Widget Functions

The rule is that the first argument for a widget function is a keyword, called the option. The pattern of the remaining arguments depends completely on the option argument. Thus

(.hello option ?arg1? ?arg2? ...)

One option which is permitted for every widget function is :configure. The argument pattern following it is the same keyword/value pair list which is used in widget creation. For a button widget, the other valid options are :deactivate, :flash, and :invoke. To find these, since .hello was constructed with the button constructor, you should see See button. The argument pattern for other options depends completely on the option and the widget function. For example if .scrollbar is a scroll bar window, then the option :set must be followed by 4 numeric arguments, which indicate how the scrollbar should be displayed, see See scrollbar.

(.scrollbar :set a1 a2 a3 a4)

If on the other hand .scale is a scale (see scale), then we have

(.scale :set a1 )

only one numeric argument should be supplied, in order to position the scale.

1.5.2 Widget Constructor Argument Lists

These are

(widget-constructor pathname :keyword1 value1 :keyword2 value2 ...)

to create the widget whose name is pathname. The possible keywords allowed are specified in the corresponding section of See Widgets.

1.5.3 Concatenation Using ‘:’ in Argument List

What has been said so far about arguments is not quite true. A special string concatenation construction is allowed in argument lists for widgets, widget constructors and control functions.

First we introduce the function tk-conc which takes an arbitrary number of arguments, which may be symbols, strings or numbers, and concatenates these into a string. The print names of symbols are converted to lower case, and package names are ignored.

(tk-conc "a" 1 :b 'cd "e") ==> "a1bcde"

One could use tk-conc to construct arguments for widget functions. But even though tk-conc has been made quite efficient, it still would involve the creation of a string. The : construct avoids this. In a call to a widget function, a widget constructor, or a control function you may remove the call to tk-conc and place : in between each of its arguments. Those functions are able to understand this and treat the extra arguments as if they were glued together in one string, but without the extra cost of actually forming that string.

(tk-conc a b c .. w) <==> a : b : c : ... w
(setq i 10)
(.hello :configure :text i : " pies")
(.hello :configure :text (tk-conc i  " pies"))
(.hello :configure :text (format nil "~a pies" i))

The last three examples would all result in the text string being "10 pies", but the first method is the most efficient. That call will be made with no string or cons creation. The GC Monitor example, is written in such a way that there is no creation of cons or string types during normal operation. This is particularly useful in that case, since one is trying to monitor usage of conses by other programs, not its own usage.