The fundamental paradigm of most computer languages, including the Wolfram Language, is that input is given and processed into output. Historically, such input has consisted of strings of letters and numbers obeying a certain syntax.

Starting in Version 3, the Wolfram Language has supported the use of two-dimensional typeset mathematical notations as input, freely mixed with textual input.

Starting with Version 6, a wide range of non-textual objects can be used as input just as easily, and can be mixed with text or typeset notations.

The "value" of this slider when it is given as input is determined by its position, in this case an integer between 1 and 10. It can be used anywhere in an input line that a textual number or variable name could be used.

How to create such controls is discussed in the next section, but it is worth noting first that in many cases there are better alternatives to this kind of input.

But there are situations where using a control inside a traditional Shift+Return evaluated input works better. Some cases are: if the evaluation is very slow, if you want complete flexibility in editing the rest of the input line around the control(s), or if the point of the code is to make definitions that will be used later, and the controls are being used as a convenient way to specify initial values.

These color swatches provide an informative, more easily edited representation of the colors than would an expression consisting of numerical color values.

The most flexible and powerful way to create anything in the Wolfram Language is to evaluate a function that returns it.

These examples use Slider, but the same principles apply to any controls. Control Objects lists all the available control objects.

The resulting slider object can be copied and pasted into a subsequent input cell just as if it were any other kind of input. (Or you can just click in the output cell and start typing, which will cause it to be converted automatically into an input cell.)

Controls created this way are inert to evaluation.

When evaluated, the slider remains a slider, which is not wanted in this case (though it is very useful in other situations). What is needed instead is a slider that, when evaluated as input, becomes the value it is set to, rather than a slider object.

When DynamicSetting is wrapped around a slider and evaluated, the new slider looks identical to the original one, but has the hidden property of evaluating into its current setting.

The examples in the previous section were created using DynamicSetting in this way.

While copying and pasting can be used very effectively to build up input lines containing controls, it is often most convenient to use Evaluate in Place Ctrl+Shift+Enter (Command+Return on Mac) to transform control expressions in place, especially once you are familiar with the commands that create controls.

All the arguments of Slider can be used to change the initial value, range, and step size.

Note that the control expressions do not contain a dynamic reference to a variable as they normally would (see "Introduction to Dynamic"). Controls used in input expressions as described here are static, inert objects, much like a textual command. They are not linked to each other, and nothing happens when you move one, except that it moves. Basically they are simply recording their current state, for use when you evaluate the input line.

It is possible to use whole panels containing multiple controls in input expressions. Constructing such panels is more complex than simply wrapping DynamicSetting around a single control, because you have to specify how the various control values should be assembled into the value returned when the template is evaluated.

The function Interpretation is used to assemble a self-contained input template object, which may contain many internal parts that interact with each other through dynamic variables. The arguments are Interpretation[variables,body,returnvalue].

The first argument gives a list of local variables with optional initializers in the same format as Module or DynamicModule. (In fact, Interpretation creates a DynamicModule in the output. See "Introduction to Dynamic".)

The second argument is typeset to become the displayed form of the interpretation object. Typically it contains formatting constructs and controls with dynamic references to the variables defined in the first argument.

The third argument is the expression that will be used as the value of the interpretation object when it is given as input. Typically this is an expression involving the variables listed in the first argument.

As with the single controls in earlier sections, these input templates can be copied and pasted into new input cells, and they can be freely intermixed with textual input.

These examples are fairly generic: they look like dialog boxes in a lot of programs. But there are some important differences. For example, note the in the input field. Input fields in the Wolfram System may look like those in other programs, but the contents can be any arbitrary typeset mathematics, or even graphics or other controls. (See the next section to learn how to write templates that can be nested inside each other.)

Wolfram System templates (and dialog boxes) are also not restricted to using a regular grid of text fields.

Whether it is useful to make a template like this or not depends on many things, but the important point is that in the Wolfram System the full range of formatting constructs, including text, typeset math, and graphics, is available both inside and around input fields and templates.

Templates defined like those in the previous section do not work as you might hope if the variables given in initializers already have other values assigned to them (for example, if the variable x has a value in the previous section), or if template structures are pasted into the input fields. To deal with evaluation issues correctly, it is necessary to use InputField objects that store their values in the form of unparsed box structures rather than expressions. (Box structures are like strings in the sense that they represent any possible displayable structure, whether it is a legal Wolfram Language input expression or not.)

Note how the InputField grows automatically to accommodate larger contents. (This behavior is controlled by the FieldSize option.)

Graphic objects, including the output of Graphics, Graphics3D, plotting commands, and graphics imported from external image files, can all be used as input and freely mixed with textual input. There are no arbitrary limitations in the mixing of graphics, controls, typeset mathematics, and text.

Notice how the plot appears in several different sizes depending on its context. There are three standard automatic plot sizes, the largest if the plot is by itself in an output, smaller if used in a list or table output, and smallest if in a textual input line. This is mainly a convenience to make graphical input less bulky. You are always free to resize the graphic by clicking it and using the resize handles, or by including an explicit ImageSize option.