Button Bar Form Element

The Button Bar form element displays one or more buttons that the user can click to perform an action.

Example of a Button Bar form element with two buttons, shown in a Geocortex viewer

Buttons are used to control form validation and submission. When you configure a button, you specify whether the button validates the user's input and/or submits (exits) the form. When the user clicks the button:

Validation: If the button's Causes Validation checkbox is selected, each form element that has validation configured is validated. If there are errors, the user is prompted to make corrections. When the user clicks the button again, the form is revalidated. The validation cycle is repeated until the form is free of errors.
Submission:

In either of the following scenarios, Causes Validation must be checked for a submit subworkflow to run.
- Value: If the button has a Value but not a click event, the submit subworkflow runs (if there is one) and the form is exited. The workflow continues running at the next activity following the Display Form activity.
  
  or
- Click Event: If the button bar has a click event, the click subworkflow runs. If the click subworkflow contains a Propagate Form Event activity, after the click event completes, the submit subworkflow runs (if there is one) and the form is exited. The workflow continues running at the next activity following the Display Form activity.

Footer Button Bar

The most common use for the Button Bar form element is to submit or cancel the form. When you create a new form in Workflow Designer, the form has a footer button bar with Submit and Cancel buttons. The Submit button validates the user's input and submits (exits) the form. The Cancel button submits the form without validating the user's input. For many forms, the default footer button bar is all you need to handle form validation and submission.

Unlike button bars that you add to a form, the footer button bar is always positioned at the very bottom of the form. You cannot delete the footer button bar. If you do not want your form to have a footer, clear the button bar's Visible checkbox to hide the button bar.

Footer button bar, shown in a Geocortex viewer

Button Bar Properties

The Properties table describes the properties of the Button Bar 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:

If a property can be accessed in both the Properties panel and expressions, then the table gives both versions of the name.
If a property's name in the table starts with a lower case letter, then you can only access the property in expressions.
If a property's name starts with a capital letter and the table does not give a name to use in expressions, then you can only access the property in the Properties panel.

Properties of the Button Bar Form Element

Buttons

Type: { [key: string]: Item; }

Name in Properties Panel: Buttons

Name to Use in Expressions: items

The buttons in the button bar. For information on configuring the buttons, see Configure the Buttons in a Button Bar.

The buttons are stored in an object called items. Each button is a property of the items object. To access the items object:

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

For example:

$form1.state.buttonBar1.items

For more information, see Form Element Items.

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.buttonBar1.visible

Enabled

Type: Boolean

Name in Properties Panel: Enabled

Name to Use in Expressions: enabled

Indicates whether the button bar is enabled in the running workflow. When a button bar is enabled, the user can click the buttons. When a button bar is disabled, the user can see the button bar but cannot interact with it. Disabled elements appear dimmed or shaded in the running workflow.

By default, button bars are enabled. To disable a button bar, 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.buttonBar1.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.

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.buttonBar1.styleName

Title

Type: String

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

You can format the title using Markdown.

type

Type: String

The variety of form element. Button bars are type "ButtonBar".

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.buttonBar1.type

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, button bars 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.buttonBar1.visible

Button Bar Events

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

Events for the Button Bar 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.

click

The click event fires when the user clicks a button in the button bar.

You could use the click event in a Clear button to remove the user's entries and reset the form to its initial state.

By default, the built-in submit behavior does not work when the button bar has a click event. The built-in submit behavior is to run the submit subworkflow, if there is one, and then exit the form. If you want the built-in submit behavior to work, add a Propagate Form Event activity to the click subworkflow. The Propagate Form Event activity instructs the workflow to perform the submit behavior after the click subworkflow completes.

submit

The submit event fires after the user clicks a button that submits the form and has Causes Validation checked, and all the elements in the form pass validation.

The submit event is your last opportunity to perform custom behavior before exiting the form. You could use the submit subworkflow to log information.

Configure the Buttons in a Button Bar

As part of the configuration of a button bar, you must configure the buttons in the button bar. There are two ways to do this:

Manually: If you know exactly how many buttons you want and how you want them labelled, you can define the buttons manually when you configure the button bar.
Using a Subworkflow: If you want to base the buttons on dynamic information like query results, you can add a subworkflow that creates the buttons when the workflow runs.

Configure Buttons Manually

If you know exactly how many buttons you want and how you want them labelled, you can define the buttons manually when you configure the button bar.

To manually configure the buttons in a button bar:

In the Buttons area of the button's properties, make sure Configure them manually is selected.
Configure a button:
1. Click the arrow to show the button's properties.
2. Label: In the Label box, type the text that you want to appear on the button.
3. Value: If you want the form to submit (exit) when the user clicks the button, enter a value that uniquely identifies this button.
  
  If you do not want the form to submit when the button is clicked, leave the Value property blank or add a click event with no Propagate Form Event activity.
  
  You can use the Value property to determine which button was selected. Make sure you use a different value for each button so you can test which button was clicked. Within the button bar's events, such as a click event, you can find out which button was clicked using an expression similar to this:
  =$form1.event.value
  Later in the workflow, you can find out which button caused the form to submit using the form's result output, for example:
  =$form1.result
  You can use any text for the button's value, for example, Get Another and 842 are valid values.
  
  An easy way to configure the value is to repeat the label. For example, a Submit button could have submit as its value and a Cancel button could have cancel as its value.
  
  If you plan to translate the workflow, you may prefer to use numbers as the values.
  
  If you use digits for the values of the buttons in a button bar (for example, you could give the buttons values 1, 2, 3,...), remember that these are text, not numbers. When you check which button was clicked, you must compare to the text value ("1"), not the numeric value (1). For example, you could use an expression like this as the condition for an If activity the follows the Display Form activity:
  =$form1.result == "1"
4. Default: Select the Default checkbox if you want this button to be selected in the event that the form is submitted automatically, for example, if the user presses Enter instead of clicking a button.
5. Causes Validation: Select the Causes Validation checkbox if you want the user's input validated when the user clicks the button. This validates the input in every form element that has validation configured.
Repeat the previous step for each button in the button bar. Click Add if you need to add a button.

You can reorder the buttons in a button bar by dragging each button to its new position in the list.
Remove any unconfigured buttons that are left over when you finish the configuration.

To remove a button, click the arrow to show the button's properties and then click Delete.

Use a Subworkflow to Create Buttons

Workflow Designer provides a Blank template that you can use as the starting point for the subworkflow that creates buttons. Initially, the subworkflow has an Event block and nothing else in it. You will have to create the subworkflow from scratch.

To create the subworkflow, first build a list of form element items, and then use the Set Form Element Items activity to assign the items to the button bar.