The Pulldown Menu is a single input list object. It appears on the form as a textfield with an arrow in the right corner and when the element gains focus it expands downwards to display a list of options for the user to select from.
This is a common element when the desired inputs are known at the time the form is being designed. Having a list of valid, pre-defined values in a list for the end-user not only makes the form more user-friendly since there is no typing involved, it ensures data integrity by eliminating possible spelling or keying mistakes by the user.
There are a range of properties and functions available which make the pulldown menu a very versatile object.
Labels and Values: There are a few ways to populate the values of a pulldown menu. The easiest way is to simply key the values into the field provided. In the example below the values entered are 1, 2 and 3. Values are the underlying core data from the pulldown menu and represent what gets stored in the XML and used in the database. The label field allows the designer to change what gets displayed to the user on the form. In this screenshot, we want the user to see the items ‘A’, ‘B’ and ‘C’ in the pulldown menu, but we want to store the corresponding values ‘1’, ‘2’ and ‘3’ in our database. Another common example is to display ‘Yes’ and ‘No’ while recording ‘Y’ and ‘N’ or ‘1’ and ‘0’. If no label is entered the system will display the value by default.
Hide and Show: This is discussed in greater detail in the next chapter, but the general idea is that sections of the form can be open and closed based on selections in a pulldown menu. For instance you can set a detail section to display only when the value in the pulldown menu is ‘1’ from the example on the previous page while hiding the same section if the user selects ‘2’ or ‘3’.
No empty item: by default there is a null selection as the first option in every pulldown menu, it allows users to basically “unselect” a value if they picked one. This null selection can be removed by enabling this checkbox.
Editable: it is sometimes necessary for convenience to provide users a list of options to make data entry more efficient, but the list may not be all encompassing and the user may need to add their own entries. If not considered detrimental to the integrity of the data being captured, designers can enable this property so that the element behaves as a combination pulldown menu/textfield. Users can select an option, or input text.
Lookup Reference Field and Lookup Reference Field Event: This property indicates that other values on the form are dependent upon this one. Setting an event such as onClick indicates that when the value is clicked all fields which are influenced by this one will be re-evaluated. MobiTask performs this function automatically, so it’s not necessary to set it for mobile forms, but if the form is to be used on the web, then the value will need to be set.
Datasource: Select the datasource to be used to get values for this list.
Server Side SQL and Client Side SQL: Instead of entering values manually for a pulldown menu the list of values can be populated dynamically from a table. More details about DSLOOKUPS and SQL can be found at the end of this chapter.
Default Item: Set the pre-defined value for the field. Users can still select a different option from the list, but the default item will be displayed as the value when the form is created.
Type: There are three types of pulldown menus, the standard web version which is a droplist on the screen, a popup windows and a separate page which slides from the side.
Open next pulldown: On MobiTask there is the option to link pulldowns together. Instead of returning to the main page after making a selection, MobiTask can automatically present an adjacent pulldown if this property in enabled.
This property sets an additional level of filtering on submissions for users. By default there are only three levels of filters provided by the application:
- View only the user’s submissions of the form
- View the user’s group’s submissions of the form
- View all submissions of the form
The filtering condition allows form creators to specify whether a value pulled from a textfield or pull-down menu is to be used as a condition for filtering submissions that end-users can view. This property works in conjunction with the table user_filter which is where the specific permissions area set. The table has two columns; username and filter. Enter the eXFORMA username under the username column, and the value to be filtered by under the filter column.
Once the table values in user_filter are set and the element has been set as a ‘Filtering Condition’, all submissions viewed by users will be filtered according to the permissions defined in the table.
IMPORTANT: This does not provide additional permissions, but merely restricts permissions already granted based on the values in the table. Therefore a user who has view permissions to their own/group/all submissions, will still only see their own/group/all submissions – but filtered down based on the conditions set by this submission filtering function.
A form with a pull-down menu (Values: City1 and City2) is created, and has the pull-down menu set as a Filtering Condition by selecting the checkbox in the element properties. The user Bob is to see all submissions related to City2, but NO submissions related to City1. The user John can see all submissions.
In order to ensure that Bob does not see any submissions related to ‘City1’, the following values need to be inserted into the user_filter table:
Notice that the user John has access to ‘City1’ AND ‘City2’ submissions in the table, while Bob can only see submissions related to ‘City2’. Now when this form is submitted with a value of City1, user Bob will not be able to see the submission.