Two findings from the review of e0dfc10:
- trResultFormValue stringified the stored value, so a numeric result
(an API-authored or hand-imported script - the engine reads ints as the
value) was misread as hex: 10 showed as '10 - cancel' (0x10) instead of
the value 0x0A, 16 matched no option and fell back to '00 - ok', and
saving the step wrote the shown option back, silently changing the value.
Numbers are converted to their hex form first.
- trResultRowHtml rendered the 'tr-addinfo-list' datalist on every call, so
the drain's form (respond + first) carried two elements with the same id.
It is rendered once per form (an opts.list flag on the first result row;
the second row and the source pin the single occurrence).
Tests: the numeric form values, the datalist only with {list: true} and the
two-row composition rendering exactly one. 855 frontend + 838 Python.
catarrh
02a78fcca6
