Element Field Properties for each HTML Element

There are many different types of HTML elements available to form designers to create e-Forms. As shown previously many of these elements share common properties, but each has features that are unique. This section will explore in detail all the HTML elements that are available and then functionality of each will be explained. 

The Attachment


The attachment element as pictured allows form submitters to attach files to the form before they submit it. The attachment is then tagged and stored with the submission in the repository. The attachment element can be restricted to limit users to a maximum upload size, a maximum number of files, and specific file types.

The attachment is tagged in the XML as follows: <attachment2> ReleaseNotes.docx|363306.docx</attachment2>

The system provides a generic random name for the file automatically and saves the file under that name within the file system.

The attachment can be found in the file system with the following relative path


Example: ..\eforma_home\upload\236@\299\363306.docx


Currently the mobile client does not support the ability to attach objects to a form. This is strictly a web use feature.

Automatically Date


The Autodate element creates a textbox on the form with the current date populated into it. The date can be presented in multiple formats according to the needs of the form designer. The field can also be hidden from form view so the end-user doesn’t see it. This object shares many similarities with the Calendar element and it is the plan to phase it out with future versions.


MobiTask does support the use of the Autodate element, but all of the functionality as well as additional enforcement controls are only available through the Calendar element. The Autodate element will be phased out in future versions of eXFORMA.

Barcode, Barcode Reader and Barcode User Generated

The barcode element allows the designer to create a unique barcode or numerical id for every e-Form submission made. This barcode can then be sent out in an e-mail and used for identification of the e-form submitter, such as a proof of purchase or the scan code on an event ticket.

The type of identification refers to a visual barcode or the equivalent numerical id. Using a visual barcode will generate a graphic image similar to the one shown below.

To use this feature a list of predefined codes must be inputted by the administrator into the application under the system admin section. Instructions for doing this are referenced in the admin section of this document.




While MobiTask does not directly support the creation of barcodes on the mobile device, form submissions created from MobiTask which contain barcode elements will have that functionality executed when the server processes the submission.



The button element places a clickable box known as a button onto the e-Form. Buttons can be used for multiple purposes but most commonly for executing predefined actions. eXFORMA has two pre-defined actions doDBConnectors and doDBExport. Both use the Connector element to define the actual action, but the former strictly executes the connector within the form, the later, executes the connector and exports the result set in the format specified.

Form designers can also enter their own ‘on click’ event by adding custom JavaScript to the element.  This allows the designer to perform actions like reading from or writing to a data source at a user triggered time as opposed to the ‘onLoad’, ‘beforeSubmit’, and ‘onSubmit’ functions of the connector.

If the form designer defines a ‘Manual’ type connector, the ‘name’ of the connector will appear on the ‘DB Connector’ property of the button element. Looking at the image above we can see that there is a manual connector created with the name ‘manualConnector’. By selecting this connector and clicking ‘apply’ eXFORMA automatically generates the ‘Click-Event’ script for the button to execute the connector


Using a Button to create an export file:


Using a Button to Hide/Show a section of the form (where div# is the table number you want to hide or show):

event_hide(‘div5′,’true’);  –hides table 5

event_show(‘div6′,’true’);  –shows table 6

Double Entry

The Double Entry element is a web-based element used to confirm entry by a user. Common for validating emails and passwords, the system automatically checks if the two entries are identical before allowing the form submission to proceed.


Masked: When enabled it masks the user entry, usualy for password entry where the entered values should not be displayed on the screen.

Case-sensitive: whether case will be assessed when determining if the two entered values are considered equal.

On MobiTask: The feature is not yet supported.

Draw On Image

The Draw-On Image object is similar to the take picture object in that it allows the user to mark on an image. The difference between the two is that the image to be marked on is provided to the user as opposed to taken with the device camera. Administrators actually have two options, they can upload an image for all users to use, or they can let the user upload their own image from the web. The actual mark-up requires MobiTask as the web element does not allow users to draw on the uploaded image.



Select Image: This is where you can upload the image as an administrator, it will be the same image for all end-users.

Input panel width, height (px): The resolution/size of the image as it will appear on the form. (600×400 and 720×540 are good sizes for more detailed images).

Allow users to upload: This property provides a control (on the web only) to allow users to upload their own image for marking.

Embedded Document

This element allows form designers to embed support documentation into the form. The element is only available via the web however and is not supported my MobiTask.

Embedded documents appear as attachment links within the form and the user can download the document for viewing.  There are no restrictions on the types or sizes of attachments.

To attach a document to a form, browse to the document using the navigation feature and select the documents path.


Text: The label that appears as a link on the form for users to download the file

Title: The title of the document

Name: How the file name will be saved when the document is downloaded.

Target: The target is an HTML reference attribute which tells the browser how to open the attachment.

_blank causes the link to open in a totally new browser window, leaving the page with the referring link still open behind it

_self loads the attachment within the same frame as the link tag

_top causes the attachment to load in the full body of the window

_parent is similar to ‘_top’ but will open the attachment in the immediate parent of a frame.

E-mail notification

The Email Notification Element can be used to send out a message to specified people upon the submission of the form. The form designer fills out the required properties as if sending an e-mail (To, Subject, CC, etc.), and selects the format which the e-mail should be sent in.



The email notification element supports the use of field references for most of its properties. In the case of the ticket, the email address of the end-user may not be known until the form is completed, so the designer can write the reference to the field that will capture the email in the ‘To:’ property of the element. Using this technique an entirely dynamic email notification can be created by using field references for the to, cc, subject, organization, and even within the body of the email.

References are specified as $(reference).Body: The body of the email message can be done in HTML, which allows for customizable e-mails to be sent out. An example of an electronic ticket is shown here. This was created with an HTML tool and imported into the body property of the

email notification. In this instance a ticket was emailed to the end-user upon submission of the order form – the barcode element used to create the ticket identification.

Attach copy of submission: If there is a print file to go with the submission you can attach it automatically by enabling this property. The system will generate the file temporarily for the purpose of generating the notification and then remove it.

Send notification for each revision: If the form is to be passed through a workflow process (like approvals), then checking this property will fire the notification on each step or revision.

Run on schedule: You can specify a specific date to run the email or you can pass a value through a reference. If no schedule is specified the email will be fire immediately, subject to any imposed delay by the system administrator in the system preferences section as discussed in chapter 3.5 System Preferences.

Send on condition: the condition that must be met for the notification to be fired.

Situational Example:

For instance you want to send a copy of a service report or inspection to your client, but only after it has been reviewed and approved.

You would check the box for attach a copy of the submission, you would also check the box for send notification on each revision, and then enter a condition for sending the message like $(status) = ManagerApproved.

Form Style

Currently allows form designers to set the overall cell padding within the form, which is its only property.

In the future it may be used to allow designers to adjust multiple design properties throughout the form such as background color, font face, etc.

There are three levels in an e-Form where design can take place, at the Form Level, the Table Level and at the Element/Field Level. Therefore it is important to understand the hierarchy of these settings. Form Style is highest level of style that can be applied to a form and it affects every table and field on the form. A Table Style is the next level down. It affects only the specified table. Each table can have its own style, and if not assigned one, it inherits the settings of the Form Style. So it is possible to set the style for an entire form, and then just modify individual table sections as needed. Finally there is the Field/Element level settings, which can be found in each elements properties, usually under the ‘label’ or ‘html’ properties section. Setting the style at the field level is the most specific style that can be assigned. Assigning a colour to a background or font at the field level will override and setting set at the form level or table level, but only for that specific element.

It is good practice to set the style at the form level first, and then adjust each table and element as needed, so if there are changes required in the future they can be made at the most appropriate levels.

GPS Coordinates

Group Object


The group object is strictly a MobiTask feature and is used as an alternative to pagination. It allows designers to group fields together and place them on separate pages to keep the form design clean and make entry easier.

Ids: The field id numbers which will be grouped together.

Page Title: Simply the label that appears at the top of the grouped page

Button Label: The text that will appear on the “button” used to open the group. This can be straight text, or it can be dynamic and reference values within the group to show users a summary of the data contained within.

On close: The SQL on MobiTask that will be executed at the time the group is closed.

Elements visible on form: These are the elements within the group that are to be displayed as a summary on the main form page. Reference the id of a space or table style if you don’t want any elements visible on the form. This property is typically used only with the button style “button”

Elements visible on panel: The id’s of the elements that are to be displayed within the group if they are different than what is specified in the ‘Id from’ and ‘Id to’ fields.

Non-persistent group: A group will retain the values of the fields contained within it as part of the form. But a group can also be used as a sub-form and the values dropped from the form after you’re finished with it. Enabling this property will prevent the form from retaining any of the data contained within the group.


Button Style: There are three styles for displaying a group on a form. The first is the basic button, which when clicked will open the group page. The second is the list item, where the group appears as a list item (multiple list groups shown on the image above), and finally a collapsed style, which opens the group of fields on the form below it (similar to a hide/show function).

Design Tip

Below is an example of an a police incident report. The number of vehicles involved in the incident (if any) can range from 1 to N and there is a fair amount of information to be captured about each vehicle. The repeat object handles the unknown number of vehicles, allowing the officer to ‘Add Vehicle’ but we wouldn’t want to display the information for say 10 all on the main form page. Using a group, each vehicle can be stored on a sub-page and summary information displayed on the main page to distinguish which vehicle information is within each group. In this example we used a “list” styled group, with a Button Label ‘Vehicle: $(year) $(make) $(model) Color:$(color).




Used mostly for capturing signatures, the handwriting object uses the input interface to capture motion and stores it as an image file. On a touch screen device this is typically done by tracing ones finger across the screen, or using a stylus. On a non-touch device, like a PC or Laptop, you can use a mouse, trackpad, or stylus pad.

The object will work on the web, provided the browser being used supports HTML5, if not then no input can be recorded. On MobiTask an input screen will pop open when selected. The size of the input panel is specified within the objects properties, and is related to the resolution of the captured image. The administrator can also choose the format of the image which will be stored.

Handwriting objects are stored within the XML and database as Base64.



HTML headings can be placed in the e-Form by using this Heading element. The heading level, font type, and line height are all easily adjustable. Colspan can be used to set the number of eXFORMA cell columns the element can span (or occupy).


Hidden Data

The Hidden Data element allows for data to be calculated in the background while the form is still not submitted. For example, calculating the final price on an item with tax, to be displayed after the user has completed the input of their order. There are two general uses for the Hidden data element, one is to hold information that may be required elsewhere but shouldn’t be displayed, the second is for calculations.

For help with formula’s and doing calculations on a form see the ‘Calculations’ Section in this manual.


Horizontal Line

This element draws a horizontal line across the e-Form that is often used to separate sections of a form. A line’s thickness, colour and the number of columns that it will span can all be adjusted from the properties.





The Image element inserts an image into the e-form. Use the browse button to navigate to the desired image directory structure, select the image and load it in. Once the image is selected and loaded it can be adjusted for width and height, as well as aligned within the cell space. eXFORMA can also draw a border around the image and add ‘mouse over’ text that will appear when the mouse pointer is over top of the image on the form.


Line Space

The Line Space element is used to inserts an empty row onto the e-Form. Used for design purposes to create proper spacing between elements on a form. When left unchecked a line space can be used to occupy a rows cell space, which can be used to adjust the spacing of elements in a row.


Multiple Selection Box

Multiple Select Boxes are used on a form to retrieve multiple selection input from the form user. Unlike a pulldown menu which supports only one selection, all, some or none of the items in the list can be selected.

One of the nice features of the eXFORMA multiple select box, like the radio button, checkbox and pulldown elements, is the ability to store and display information differently. Use the ‘Items’ list to store the entries and use the ‘Text’ list to modify the text as it appears on the menu in the form.

Each value is separated by the <enter> keystroke, and the first value of the Text property corresponds to the first entry in the Item property and the second value in ‘Text’ corresponds with the second value in ‘Items’ and so forth.

Multiple Selection Boxes can often get very large with options, even showing all 12 months like the example below would take a lot of space on a form, so the visible size of the selection box can be controlled and the form user would use the arrows on the scroll bar to navigate through all the selections.


Ordered and Unordered Lists

The Ordered and Unordered Lists Elements are almost identical in both properties and behaviour. The list is generated from the ‘Items’ property of both elements. For an ordered list, just input the number that the list will start with, and eXFORMA will number the list automatically. For an unordered list, select the list type, and then select the alignment (‘style position’) eXFORMA again takes care of updating the list automatically.


Page Break Point

Inserting this element into the e-form will break the e-form into two pages, or three or four depending on how many page breaks the designer adds. Any element below the Page Break Point will be placed on the next page of the e-form, which the user can reach by clicking the Next button at the end of the form.

It is important to note thought that hide/show functionality CANNOT be split by a page break element because the table sections re-number after the page break. This functionality can still be achieved using JavaScript code on the elements but it does require programming knowledge.


The Paragraph element is used to insert large sections of text with the same formatting onto a form. Like similar elements a ‘Paragraph’ may be styled to fit within a single column in one of the tables, or it may span across as many columns as the designer requires.

The key to remember with paragraphs is that all text contained within the element holds the same formatting.

Password Field

The Password Field works like a textbox. The only difference is that all characters inputted by the user are displayed as ‘*’.  As with a textfield the input can be validated to make sure it has numbers, words, or is in the form specified by the designer. The password length can be restricted, and the length of the textbox can be adjusted based on visual design needs.


Rich Text Area

A Rich Text element is a larger text area with an editor which allows the user input of text on a form. The editor can be sized by the form designer to limit the number of rows and columns of characters. There are two types of editors to choose from; Simple and Advanced. As shown below there is significantly more editing and styling capabilities with the advanced editor than with the simple editor and as such also takes more data space in the submission file. So always be aware of how much data you can afford to capture.



The sentence element allows the form designer to place a line of text onto a form. Essentially acting as a label field, the sentence element can be set to span any width and styled to fit the designer’s needs. The sentence element can also be used to place a hyperlink on the e-Form.


On MobiTask

The ‘Style’ property is supported, as is the width and color properties. Properties related to Font face, size and alignment are not supported on the mobile client.


The Space element is strictly used as a space holder within the form designer. It has no inherent function on web design or on the mobile client. It can be used by designers to save ids for use at a later date. If a form is going to have a lot of calculations, groups, and repeats, which rely on Ids within their properties, then it is a good idea to intermittently place some space elements throughout the form. Then in the future if you need to add a field you can just replace a “space” and not have to re-do the ids on the other properties. The same if you need to remove a field, just replace it with a space and you don’t have to worry about adjusting the ids on any of the other element properties.

Take Picture

Action Script Editor

We have added a property to our Textfield element for accepting a limited range of custom action script code to provide an additional level of validation for our clients.

To support this property we have added an Action Script development editor to our MobiTask client application (version 2.0.11 +), which will be available for download on all major marketplaces next week.

To access the Action Script editor run MobiTask and input gr0v3v2r3@dmin as the username and press the login button.


The Action Script editor window will open as shown below.


This editor is divided into 3 input areas, one for entering test values, one for the result and the largest one for entering the function.

There is a demo function in the display already which is a function to checks for the presence of a numerical value in a string. If you enter sample data ‘123456’ in the test string and press run, the return message is ‘Correct Input’. If you were to enter 12345s’ in the test string and press run, the return message will be ‘Correct Input’. If you enter ‘asf’, the return value will be ‘invalid input’ because ‘asf’ does not contain a numerical digit.

There are some limitations with this for the time being.

1.  The structure of the function cannot be changed. This means the function name, function parameters and return value MUST remain the same.

2.  The only valid input will be the user inputted value of the respective textfield.

3.  If the input value is valid, the validation function shall return an empty string.

Once you have generated your validation function you will need to copy it from this Action Script editor into the form editor.

The textfield element on the form editor has been updated to include a property under the ‘others’ section called ‘Action Script Function’.


Paste the function into this field and apply the changes on the form.


In version 2.0.10 of MobiTask we added a feature to support using lookups to populate fields of data from a datasource.

We have added to this feature to provide an additional level of control with respect to filtering and selecting of data using SQL.

When you create a dslookup on a form you will now find an additional SQL box dedicated to MobiTask. When originally created The SQLite script had to match the existing datasource script which limited this feature to only supporting simple syntax common to each datasource.

Now users can input a statement for the web-form in the first box which is written in the SQL syntax of the datasource and then a second statement written in the SQLite syntax which will be used by MobiTask.

It is important to note that any existing SQL already written will need to be copied to the SQLite entry field for you MobiTask forms to continue working properly.


Random Notes

additional variables: $_cr and $_lf to generate CR/LF characters

[10:36:14 AM] Igor Karfidov: also… don’t forget that you can use $searchFilter in pulldown lookups. online and offline. it’s the textbox where you search  on the page with list of values

[10:37:21 AM] Igor Karfidov: select name as label, id as value from some_table where name like ‘$searchFilter’ 🙂 should work

[10:38:04 AM] Igor Karfidov: it improves search performance on the server side when you have your search fields indexed.



Contact Form Powered By : XYZScripts.com