Perspective Table Shows 0 Because Column Formats Round Doubles

A Perspective Table showing 0 in cells that hold doubles near 1×10^-4 is a display problem. The data is intact. The column's default number format keeps only a few decimal places, so the rendered text rounds to zero. The Table component has no table-wide number format property. Formatting is set per column object in props.columns. On a 20- to 30-column table, don't edit each column by hand. Bind props.columns to the source dataset and build one column object per field, applying the exponential format to every floating-point column.

Why does the table show 0 when the data holds 1e-4?

The value passes through four stages before it is drawn:

1. The source (named query or historian) returns a dataset.
2. The dataset is written to props.data.
3. The Table matches each data key to a column object in props.columns by its field value.
4. The column's render mode and number format turn the double into text.

A value of 0.0001 formatted to two decimals is 0.00, and the default format trims that to 0. Any column with no matching entry in props.columns uses the default. A correct entry with an exponential format shows the full magnitude. Fix the value at stage 4. Converting the numbers upstream to strings breaks sorting and filtering.

Is the value small, or already zero before it reaches the table?

Measure before you change anything. Look at the raw value first. If the source already returns zero, no display format will recover it.

If the raw result is correct and props.data is correct, go to the next check. If the raw result is already zero, fix the query or tag history aggregation. Stop working on the table.

What does props.columns contain right now?

Expand props.columns in the Property Editor. Three outcomes decide the next step:

• Empty array: The Table creates columns on the fly with default formatting. Build the array with a binding (procedure below).
• Entries shown as quoted strings instead of expandable objects: A script returned JSON text, not objects. The Table cannot read field or format keys from a string. Read the next section.
• Objects present, but some cells still show 0: Compare each field with the data key, including case. A mismatch leaves that data column on defaults.

Why does a string-template script for props.columns fail?

A common first attempt builds each column as a triple-quoted JSON string and fills in the header with .format(headerName=header). That approach has two failure points:

• Brace collision: str.format reads every { and } as a placeholder. The JSON object's own braces then throw a key or format error, unless you double them all as {{ }}.
• Wrong return type: Even when formatting succeeds, the function returns a list of strings. Embedded newlines and indentation go into the property as literal text, which shows up as the newline problems. props.columns needs a list of dictionaries.

Build the template once as a dictionary, copy it for each column, and set field. The script then never uses string formatting.

How do I generate props.columns from the dataset?

Use this layout: one binding pulls the dataset into a view custom property, and two property bindings feed the table from it.

1. Configure one column by hand in the Designer. Set its field, set render to number, and pick the exponential number format. Check that it displays 1×10^-4 correctly.
2. Right-click that column object in the Property Editor and copy it. This JSON is your template, with every key named exactly as your Ignition version expects.
3. Move the query or historian binding off props.data and onto a view custom property, for example view.custom.sourceData. Keep the return format as a dataset so the column names and types stay available.
4. Bind props.data to view.custom.sourceData.
5. Bind props.columns to view.custom.sourceData as well, with the script transform below. Paste the copied JSON into the two templates.

Replace the short template bodies with the full objects you copied, including the number format key and its exponential pattern. system.util.jsonDecode handles JSON true, false, and null, so you don't need to change the pasted text. Integer and string columns get the plain template, so only the small doubles switch to exponential.

If the source columns never change, a script transform is fine. For large or fast-refreshing datasets, the transform runs on every update. A third-party expression-function module, such as the Integration Toolkit from Automation Professionals, can build both props.data and props.columns from a dataset without Python transforms.

How do I confirm every double column renders in exponential form?

1. Expand props.columns. Each entry must be an expandable object, not a quoted string, and the count must match the dataset column count.
2. Pick a row with a known value near 1×10^-4 in the query browser. The same cell on the table must show the mantissa and exponent, not 0.
3. Sort a double column. The order must be numeric, which confirms the data stayed numeric and only the display changed.
4. Change the query to add or rename a column. The new column must appear with the correct format without any Designer edit.

Recurring faults on this setup:

• Someone edits props.columns by hand in the Designer, and the next binding evaluation overwrites the edit.
• The query aliases change case, so the field values no longer match.
• The dataset is converted to JSON before the columns binding reads it, which loses the column type information the transform needs.

FAQ

Contact Inductive Automation support if these conditions hold together: the property tree shows correct column objects, the field values match, render is number, and the exponential format still shows 0. Include your Ignition version, the exported view JSON, and a sample row. That lets support check for a rendering defect in your release.