Text Area Form Element

The Text Area form element allows the user to enter one or more lines of text.

Example of the Text Area form element with two lines of text entered in it, shown in a Geocortex viewer

Text Area Properties

The Properties table describes the properties of the Text Area form element.

Property names in Workflow Designer's Properties panel are written using the capitalization and spacing of a title. Property names in expressions are valid JavaScript identifiers and start with a lower case letter. Expressions are case sensitive. When you access a form element property in an expression, you must use the correct capitalization.

In the table below:

Properties of the Text Area Form Element

Default Value

Type: String

The text that appears initially in the text area.

Description

Type: String

A description of the element. The description appears below the element's title.

You can use the Description property to describe what the element represents or to provide instructions to the user about how to use the element.

You can format the description using Markdown.

Element ID

Type: String

The element's ID, which is used in other form elements and activities to access the element's properties, including the user's input. The ID must be unique across all elements in the form.

You cannot set the value of the Element ID property in an expression—you can only use the value that you configured for it. To use the Element ID property in an expression:

${Display Form ID}.state.{Element ID}.{property name}

For example:

$form1.state.textArea1.visible

Enabled

Type: Boolean

Name in Properties Panel: Enabled

Name to Use in Expressions: enabled

Indicates whether the text area is enabled in the running workflow. When a text area is enabled, the user can enter text. When a text area is disabled, the user can see the text area but cannot interact with it. Disabled elements appear dimmed or shaded in the running workflow.

By default, text areas are enabled. To disable a text area, clear the Enabled checkbox. You may want to change the property's value at run time depending on the user's input in a previous form element.

To access the enabled property in an expression:

${Display Form ID}.state.{Element ID}.enabled

For example:

$form1.state.textArea1.enabled

error

Type: String | MarkdownRef

Indicates whether an error occurred in the element.

We recommend using the Set Form Element Error and Clear Form Element Error activities to work with errors in form elements.

Maximum Length

Type: Number

Name to use in Expressions: maxLength

The maximum number of characters that can be entered in a field.

To access the enabled property in an expression:

${Display Form ID}.state.{Element ID}.maxLength

For example:

$form1.state.textArea1.maxLength

Read Only

Type: Boolean

Name in Properties Panel: Read Only

Name to Use in Expressions: readOnly

Indicates whether the user can edit the text in the text area or not. The user can select and copy read-only text, provided the element is enabled.

Use the Read Only property to prevent the user from changing the text in the text area.

By default, the user can change the text in a text area. If you want the text to be read only initially, select the Read Only checkbox.

To access the readOnly property in an expression:

${Display Form ID}.state.{Element ID}.readOnly

For example:

$form1.state.textArea1.readOnly

Required

Type: Boolean

Name in Properties Panel: Required

Name to Use in Expressions: require

The Required checkbox is intended as a quick way to do simple validation without having to add a validate event. When you add a validate event, the Required check is not performed even if the checkbox is selected. To force the Required check to be performed when a validate event is configured, add a Propagate Form Event activity anywhere within the event's subworkflow.

Indicates whether the user must enter some text in the text area. When the text area is required, the user cannot submit the form until some text is entered.

By default, text areas are not required. To require a text area, select the Required checkbox.

To access the require property in an expression:

${Display Form ID}.state.{Element ID}.require

For example:

$form1.state.textArea1.require

Rows

Type: Number

The size of the text area, measured in rows. The Rows property controls the number of rows that the user can see at one time—it does not limit the number of rows of text that the user can enter. The user can scroll to see the other rows.

By default, text areas show 3 rows. If you know in advance approximately how many rows the user will need, you can adjust the Rows property accordingly.

To change the number of rows, you can either type the number into the Number box or click the arrows . The number of rows must be a positive integer.

styleName

Type: String

Indicates the name of the style that will be applied to the element.

To access the styleName property in an expression:

${Display Form ID}.state.{Element ID}.styleName

For example:

$form1.state.textArea1.styleName

Title

Type: String

The element's title, which appears at the top of the element. You may want to change the title to describe what the element represents in your workflow.

You can format the title using Markdown.

Tooltip

Type: String

A message that displays when the user hovers the mouse pointer over the text area. You may want to use the tooltip to provide help to the user.

type

Type: String

The variety of form element. Text areas are type "TextArea".

Use the type property to find out the variety of a form element in a form with many elements. Loop through ${Display Form ID}.state, comparing each element to the known form types and performing some action on the elements that meet your type criteria.

To access the type property in an expression:

${Display Form ID}.state.{Element ID}.type

For example:

$form1.state.textArea1.type

value

Type: String

The text that the user entered in the text area.

To access the value property in an expression:

${Display Form ID}.state.{Element ID}.value

For example:

$form1.state.textArea1.value

Visible

Type: Boolean

Name in Properties Panel: Visible

Name to Use in Expressions: visible

Indicates whether the element is visible to the user. By default, text areas are visible. If you want to hide the element, clear the Visible checkbox. You may want to change the visibility at run time depending on the user's input in a previous form element.

To access the visible property in an expression:

${Display Form ID}.state.{Element ID}.visible

For example:

$form1.state.textArea1.visible

Wrap

Type: String

Name in Properties Panel: Wrap

Name to Use in Expressions: wrap

Indicates how the control wraps text. By default, text areas use "Soft" wrapping.

  • hard: The browser automatically inserts line breaks (CR+LF) so that each line has no more than the width of the control.
  • soft: The browser ensures that all line breaks in the value consist of a CR+LF pair, but does not insert any additional line breaks.
  • off: Like soft but changes appearance to white-space: pre so wide line segments are not wrapped and area becomes horizontally scrollable.

To access the wrap property in an expression:

${Display Form ID}.state.{Element ID}.wrap

For example:

$form1.state.textArea1.wrap

Text Area Events

The following table describes the events associated with the Text Area form element. As in Workflow Designer, the events are listed in the order that they fire.

Events for the Text Area Form Element

load

The load event fires when the element finishes loading.

You can use the load event to set one or more of the element's properties at run time. For example, you could set the text area's initial value.

change

The change event fires when the user clicks away from the text area after entering or changing the input.

You can use the change event to create dependencies between form elements. For example, you could configure a change subworkflow that enables or disables other form elements depending on the user's input.

The change event fires every time the user's input changes. This means that the change subworkflow can run multiple times. Because of this, you should make sure that the change subworkflow is not computationally intensive or long running.

validate

The validate event fires when the user clicks a button that causes validation.

You can use the validate event to verify that the user's input is valid before allowing the form to submit. If the input is not valid, use the Set Form Element Error activity to display an error to the user and prevent the form from submitting. If the input is valid, use the Clear Form Element Error activity to clear an existing error and allow the form to submit.

If you use a Set Form Element Error activity, make sure you also use a Clear Form Element Error activity to clear the error. Otherwise the form may get stuck in an invalid state.

By default, the Required property does not work when the text area has a validate event. If you want the workflow to perform the Required check, add a Propagate Form Event activity to the validate subworkflow. The Propagate Form Event activity instructs the workflow to perform the Required check after the validate subworkflow completes.

For an example, see Example - Subworkflow for a Validate Event.