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 following table describes the properties of the Text Area form element. Some properties can be configured in the Properties panel in Workflow Designer. These properties have configuration information in the table. Similarly, some properties can be accessed in expressions. These properties have information about how to access the property in an expression.

If a property can be configured in the Properties panel and accessed in expressions, the property has two names: the name that appears in the Properties panel and the name that is used in expressions. Both names are given in the table. Sometimes the names only differ in capitalization, for example, Visible (in the Properties panel) or visible (in expressions).

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 get or 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 initially, 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.

MarkdownRef objects have a markdown property of type String that represents the Markdown text.

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

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

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.

The Required checkbox is intended as a quick way to do simple validation without having to add a validate event. If you add a validate event to a form element, selecting the Required checkbox will not have any effect. In this case, you must make the validate event check whether the user entered a value.

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.

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. Descriptive titles make forms easier to understand.

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 initially, 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 text area's 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.

© 2019 Latitude Geographics Group Ltd. All Rights Reserved.

Documentation Version 5.11