mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-08-13 18:14:13 +02:00
ispyisail
762bd7febf
Selecting more than one dynamic text field in the element editor silently replaced every selected field's colour with the colour of the first one. Nothing was clicked -- merely extending the selection destroyed the others' colours, and the change went onto the undo stack as if the user had asked for it. Cause: updateForm() loads the current part's colour into the colour button with m_color_kpb->setColor(). KColorButton::changed is emitted for a programmatic setColor() just as it is for user interaction, and it is connected to m_color_kpb_changed(), which applies the new colour to *every* part in m_parts. So simply displaying the first part's colour wrote that colour to all the others. Every other widget in updateForm() is immune because it is wired to a user-only signal -- on_m_x_sb_editingFinished(), on_m_frame_cb_clicked() -- which setValue() and setChecked() do not emit. The colour button is the one control whose signal cannot distinguish the two, so block it while loading. This also explains why the reporter saw it only when rubber-band selecting bottom-to-top: the write happens only when the first part's colour differs from what the button already shows, which depends on selection order. Verified in the element editor with two dynamic texts, one red and one blue: select the red one, then ctrl-click the blue one. Before: the blue text turned red. After: both keep their colours. Changing the colour deliberately with the button still applies to all selected texts, as intended.