mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-28 13:24:14 +02:00
ispyisail
3cec02b3f3
LinkElementCommand::redo() already had a check meant to catch exactly this -- two report-linked conductors whose properties disagree -- and ask the user which to keep via PotentialSelectorDialog. It never worked: it built ONE combined list from three unrelated fields (tension_protocol, wire_color, wire_section) and tested that whole list for string equality, so a tension-protocol value could never equal a wire-colour value even when every field individually matched across every conductor. Worse, "wire_color"/"wire_section" are ConductorProperties::m_wire_color/m_wire_section, a separate free-text documentation pair that says nothing about how the wire is actually drawn -- that's "color"/"style" -- so the one field #974 is actually about was never compared at all. Fixed by comparing each relevant field (text/num, function, tension protocol, colour, line style) separately. Downloaded the reporter's actual project, confirmed the mismatched wire reads color="#0000ff" on one side of a "Folio suivant"/"Folio precedent" link and color="#55aa00" on the other, with the link's other four conductors matching correctly (ruling out a rendering artifact) -- see PR #980's checkContinuity() extension, which now flags this class of mismatch on sight. Extracted the comparison into its own static reportLinkNeedsPotentialChoice(), for the same reason ConductorCreator::needsPotentialChoice() already exists as its own method: a caller with nobody there to answer a modal dialog needs to check first and decline, and the condition must not drift away from the one redo() actually applies. Fixing the comparison surfaced a real, previously-latent hang in this session's own qet.linkElements(): PotentialSelectorDialog::exec() is a plain QDialog::exec(), not routed through QET::QetMessageBox, so headless --run has nobody to answer it. Measured directly -- hung until killed with the property-comparison fix alone, clean refusal after adding the guard. linkElements() now calls reportLinkNeedsPotentialChoice() before constructing the command and declines with a clear reason, the same choice addConductor() already makes about ConductorCreator's own equivalent dialog. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>