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.
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
The Properties table describes the properties of the
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: Name to Use in Expressions: items
The ${Display Form ID}.state.{Element ID}.items For example: $form1.state. 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 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.buttonBar1.visible |
Enabled |
Type: Boolean Name in Properties Panel: Enabled Name to Use in Expressions: enabled Indicates whether the By default, To access the ${Display Form ID}.state.{Element ID}.enabled For example: $form1.state. |
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 ${Display Form ID}.state.{Element ID}.styleName For example: $form1.state. |
Title |
Type: String The element's title, which appears at the top of the element. You can format the title using Markdown. |
type |
Type: String The variety of form element. Use the To access the ${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, To access the ${Display Form ID}.state.{Element ID}.visible For example: $form1.state.buttonBar1.visible |
The following table describes the events associated with the
Events for the Button Bar Form Element
load |
The You can use the |
click |
The You could use the By default, the built-in submit behavior does not work when the button bar has a |
submit |
The The |
As part of the configuration of
Manually: If you know exactly how many
Using a Subworkflow: If you want to base the
If you know exactly how many
To manually configure
In the
Configure
Click the arrow to show the
Label: In the Label box, type the text that you want to
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"
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.
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
You can reorder the
Remove any unconfigured
To remove to show the
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.