Reported by @scorpio810 on #626: "The field does not update automatically;
you need to list the other rules for it to update."
Two reasons, both mine:
The refresh was wired to the combo boxes' activated() signal, which Qt
emits only for user interaction. Nothing that changed a context
programmatically -- which is to say, numbering an element -- ever reached
it. Re-picking a rule from the combo was not a workaround so much as the
only code path that refreshed at all.
And there was no signal to hang it on for two of the three categories:
addElementAutoNum() emitted elementAutoNumAdded(), but addConductorAutoNum()
and addFolioAutoNum() emitted nothing, so even a listener would not have
heard a conductor counter advance.
Add QETProject::autoNumContextUpdated(), emitted by all three setters, and
have the dock re-read its three fields on it. Kept deliberately separate
from the existing *AutoNumAdded/*Removed signals: those make listeners
rebuild their rule lists, which is both heavier than needed here and would
disturb the user's current selection every time an element is numbered.
This one only says "re-read me".
The automatic refresh skips a field that has keyboard focus, so numbering
an element cannot overwrite a value half-typed under the cursor. Explicit
refreshes after a reset or an edit still write unconditionally, so the
field always ends up showing the canonical stored value.
Measured, advancing a counter the way numbering advances it and without
touching the combo box:
field before advance "5"
context after advance 6
field after advance "6" (was still "5")
Follows @scorpio810's review on PR #626 and three defects found by finally
running the thing rather than only building it.
Replace the "?" button with an editable value field, as asked for. It shows
the current value of the context's counter -- the last part that actually
progresses, i.e. the least significant digit -- and typing a new value and
committing it writes that value back. This is strictly more useful than the
button it replaces: "?" is still reachable by typing it, and any other value
is now reachable too, which was the point of the request.
It also removes a destructive edge the button had: "reset to ?" rewrote
*every* part, so a scheme built as "K" + counter became "?????" and the
configured prefix was gone for good. There is no undo command for
numbering contexts.
Two bugs fixed in the reset path itself:
- The project was never marked modified. addConductorAutoNum() and friends
are a plain insert into a QMap; they emit nothing and set no dirty flag,
and the properties dialog that this code was modelled on calls
setModified(true) separately afterwards. Without it the user resets a
counter, closes the project, is not asked to save, and the reset is lost.
Verified before the fix: projectWasModified() stayed false across a click.
- A wrap part was reset to "1". A modulo part cycles over [0, modulus) --
the PLC addressing that motivated the feature runs %IX0.0..%IX0.31 -- so
its starting value is 0, not 1.
An empty value field is treated as "no change" rather than as an empty
value, so clearing the box by accident cannot wipe a counter, and the field
is refreshed from the context after every write and whenever the selected
context changes.
Resetting an active numbering counter back to a starting value, or
marking it as needing manual numbering, currently requires the full
round trip through the project properties dialog: open it from the
dock's Configure button, locate the right numbering context, select
the specific part row, clear and retype the value, confirm.
Add two small buttons next to each of the three combo boxes
(Conductor/Element/Folio) on AutoNumberingDockWidget itself:
- Reset to start: calls NumerotationContext::replaceValue() on every
part that represents a progressing counter, using a sensible
per-type value -- the part's own stored initialvalue for
folio-anchored types (unitfolio/tenfolio/hundredfolio), "1" for
plain numeric types and wrap, "a" for alpha. Non-incrementing types
(string, plant, locmach, idfolio, folio, elementline,
elementcolumn, elementprefix) are left untouched, since there's no
meaningful "start" distinct from whatever the user configured for a
fixed/contextual value.
- Reset to "?": sets every part's value to the literal placeholder
"?" unconditionally, for marking a context as needing manual
numbering.
Both write the updated context back via the same
addConductorAutoNum/addElementAutoNum/addFolioAutoNum calls the
project properties dialog itself already uses, so the dock's existing
refresh signals fire exactly as they do today.
Verified with a full build (Qt6) after the change -- clean compile
and link, including the .ui-generated Ui class correctly picking up
the six new button object names. Wasn't able to get a reliable live
GUI run in this environment to click-test the buttons themselves (ran
into unrelated session/display instability before any interaction
with the new buttons occurred), so this is verified by code review
and successful build rather than a runtime screenshot.
Implements https://github.com/qelectrotech/qelectrotech-source-mirror/discussions/597
ispyisail