mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-10-08 13:04:13 +02:00
e3a1a67c66
Before the <sequentialNumbers> element, an element's or conductor's sequential numbers were saved as the attributes sequ_1, sequf_1, seqt_1, seqtf_1, seqh_1 and seqhf_1. The readers check for one of them to take the old route, and all three lists had the same slip: sequf_1 twice, seqhf_1 never (Element::fromXml, Conductor::fromXml, and readSequence() in the project database). A file whose only old sequence was the hundred-folio one took the new route, found no <sequentialNumbers>, and lost it; the database built its labels from an empty sequence instead of refusing the fast path as it does for the other five attributes. Name seqhf_1 in the three lists. No file-format change: nothing is written differently, and a file with any of the other five attributes loads exactly as before. Tests: tst_legacysequentialattributes runs the binary's --resave on a fixture whose element and conductor carry only seqhf_1 (and a second pair carrying sequ_1 as a control) and reads the <sequentialNumbers> written back. The two seqhf_1 cases fail on master. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: Beat Hangartner <beat@hangartners.ch>