Appearance
Form Widget
Last updated
Several fields, checked together, submitted together.
The Text Input and Numeric Input widgets each write one tag the moment you leave the field. That is right for a setpoint and wrong for a record: a quality check with four fields must not be half-written because someone tabbed away.
Settings
| Setting | Description | Default |
|---|---|---|
| Fields | Target, table and the field list (below) | none |
| Submit Button Text | Label of the submit button | "Submit" |
| Clear after submit | Empties the fields after a successful or kept submission | on |
| Confirm before submitting | Asks "Submit this form?" first | off |
Where a form sends its answers
| Target | What happens |
|---|---|
| Add a row to a data table | One row per submit. This is what a record is |
| Write each field to a tag | Every field writes to its own tag, local or on a device (device tags need Allow Tag Writes and the tag's write security level) |
Warning: In this version the property panel has no tag picker per field, so a form set to Write each field to a tag has nowhere to write. Submitting it reports Saved. without writing anything. Use Add a row to a data table, or separate input widgets, until per-field tags can be chosen.
With the tag target, one failed write fails the whole submit (fields already written stay written).
Build it from the table
- Choose the target Add a row to a data table and pick the table under Choose a data table….
- Click Generate n fields from this table. You get one field per column, typed from the column (integer and real → Number, boolean → Yes / no, everything else → Text), with Required and default values from the column definitions.
- Adjust labels, order (▲▼) and types, remove fields you don't want the operator to fill in.
This is the way to do it. Hand-typing a field per column is how a form ends up disagreeing with its table. If a field's key is not a column, the panel says "These fields are not columns in the table and will be rejected on submit: …" while you can still fix it.
Field settings
| Setting | Description |
|---|---|
| Field key / column name | For a table target, the exact column name |
| Label shown to the operator | The field's caption; blank shows the key |
| Type | Text, Long text, Number, Yes / no, Choice list, Date |
| Options | Choice list only: comma-separated, e.g. Pass, Rework, Scrap |
| Min / Max | Number: value limits |
| Min length / Max length | Text and Long text: character limits |
| Required | Must not be empty |
A field's pattern (regular expression), hint text and default value exist in the saved form but cannot be set in the property panel, except defaults filled in by Generate.
Validation
Errors appear after the first Submit, not while typing, with messages such as "This is required.", "Enter a number.", "Must be at least 5.", "At most 40 characters." and "Choose one of the listed options."
- Zero is a value. A required number field accepts 0.
- An unticked required checkbox is not an error. Both states are answers.
- A broken pattern does not block anyone. An invalid regular expression is ignored.
- An optional field left blank is omitted, so the table column keeps its own default.
Before it commits
Turn on Confirm before submitting for anything that starts a process rather than just recording one. The form always says what happened — Saved. for four seconds, or the error in red — because a form that empties itself with no word is one people submit twice.
The appliance checks a submission against the form as saved. After changing a form's fields in the editor, Save the dashboard before testing it in Preview, or you will be testing the old version.
Who can submit
Operators, editors and admins; viewers cannot. An operator can submit a form on any dashboard they can open without being able to write to the data table in general. The appliance checks the answers against the form as it is saved, not as the page sent it, and writes only that form's fields.
A form on a custom page is not saved anywhere the appliance can look it up, so submitting one needs the editor or admin role, and it is never kept on the device to send later.
When the appliance can't be reached
A tablet carried down a line loses Wi-Fi in the places people fill in forms. A form that adds a table row keeps the submission on the device instead, and says so: Saved on this device. The top bar shows n waiting on every page until it has gone.
- It is sent automatically when the appliance answers again, oldest first. Send now in the top bar tries at once.
- Each submission goes in once. It carries an id made when Submit was pressed, and the appliance ignores an id it has already received — so a reply lost on the way back, or two tabs sending at once, never makes a second row.
- It is sent as the person who filled it in. On a shared tablet the next person to sign in does not send it under their own name; it waits for its owner, and the panel says one is waiting for someone else.
- It is checked again when it arrives, against the form as it is then. If the form changed meanwhile — a field became required, the table was removed — it is marked Refused with the reason and what was entered, and kept. Only a person can discard it.
- It survives closing the tab and restarting the tablet.
- Record when Submit was pressed in writes the time it was actually filled in to a text column. Without it, a submission kept for an hour is stamped with when it arrived.
- A session that has expired is treated the same way: the submission is kept until its owner signs in again.
Forms that write tags are never kept. A setpoint written an hour after it was entered is not the setpoint anyone meant, so a tag form that can't reach the appliance says it was not sent. Turn off Keep submissions on the device when the appliance can't be reached for a table form that must also only ever go in live; it then says "Not saved — the appliance can't be reached…".
Opening the app with no connection
Over HTTPS, the app itself is kept on the device, and each dashboard you open is saved as a copy for your user. A tablet that reloads a sleeping tab out of range still opens, shows the dashboard from its copy with a banner saying so, and its forms can be filled in and kept. Values on it are not live. Copies are removed when you sign out; kept submissions are not.
Browsers only allow this on a secure page. Over plain HTTP, submissions are still kept, but only a page that stays open can be used offline.
Example: a first-off inspection record
Data table first_off_checks with columns part_number (text, required), bore_mm (real, required), surface_ok (boolean), result (text), filled_at (text). Add a Form, Generate 5 fields from this table, remove filled_at from the fields, set bore_mm Min 24.95 / Max 25.05, change result to a Choice list of Pass, Rework, Scrap, and set Record when Submit was pressed in to filled_at. Put a Data Table widget on first_off_checks beside it to show the last 25 checks.