mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-08-03 18:44:13 +02:00
ispyisail
68c260342e
Adds a configurable wrap-at-N counter type to the autonumbering engine (NumerotationContext + NumerotationContextCommands), covering PLC/rack-style addressing conventions like "e0.0...e0.7, e1.0...e1.7" (8 channels per card) generally, rather than hardcoding octal specifically. - New "wrap" part type (WrapNum, alongside the existing UnitNum/TenNum/ HundredNum strategies) stores a modulus in addition to the existing value/increase/initialvalue fields. Its own next()/previous() only wraps its own value modulo the configured modulus -- carrying into (or borrowing from) the adjacent part requires visibility across parts, which only the composition loop has. - NumerotationContextCommands::next()/previous() gained carry()/borrow() helpers: when a wrap part's own next() would reach/exceed its modulus (or go below 0 on previous()), the nearest preceding numeric part is bumped by exactly one unit, skipping non-numeric parts (e.g. a "." string separator). Wrap parts chain correctly if adjacent (e.g. seconds wrapping into minutes wrapping into hours). - For the leading part of a wrap-and-carry pair to stay fixed except when carried into (i.e. actually produce "e0.0...e0.7, e1.0..." rather than advancing on every step under its own strategy), its own increase must be 0. The increase spinbox's minimum was 1, which made this configuration impossible through the UI -- lowered to 0 and documented with a tooltip, since this wasn't obvious from the UI alone. - NumerotationContext gained a 5th pipe-separated field (modulus) in its serialized string form, defaulting to 0 (non-wrapping) for every existing part type; toXml()/fromXml() persist it as a "modulus" XML attribute the same way "initialvalue" is already persisted for unitfolio/tenfolio/hundredfolio. - New "Cyclique (modulo)" entry in the part-type dropdown (numparteditorw), available for element, conductor, and folio autonumbering alike, since all three already go through NumerotationContextCommands. Verified in the running app via the numbering config dialog's own Suivant/Précédent buttons (which call the production NumerotationContextCommands::next()/previous() directly): a two-part context (unit, increase=0 + wrap mod 8) produced exactly e0.0→...→e0.7→e1.0→...→e1.7 on repeated "next", and the exact reverse (with correct borrowing) on repeated "previous".