Fix crash changing dynamic text color and confirming with Enter (bugtracker #323)
Works like charm:
- color is updated immediately
- no additional errors or warnings
- no crash anymore!
plc-user on PR #693: the crash is fixed, but the color/font field and
the on-diagram text no longer update until you leave the properties
list and click in the diagram -- previously it updated as soon as you
clicked OK.
That's a side effect of the crash fix itself. The old, crashing code
returned a *live* QColorDialog as the item view's editor; clicking its
OK button called accept()/hide() on it, and hiding the active editor
happens to trip the base delegate's own focus-lost commit path -- so
the value applied immediately, racily, as a side effect of the same
mechanism that crashed on Enter. The fix (commit 4bd9b6b21) replaced
that with running the dialog synchronously inside createEditor() and
returning an inert placeholder with the result stashed in a property.
Correct for the crash, but it also removed that accidental commit
trigger: the placeholder never had focus to lose, so nothing tells
the view to read the value back until some unrelated interaction
(clicking away) incidentally triggers it.
Fix: explicitly emit commitData()/closeEditor() for the resolved
editor, deferred via QTimer::singleShot(0, ...) since the view only
registers createEditor()'s return value as "the active editor" after
createEditor() itself returns -- emitting synchronously, before
returning, would target a widget the view doesn't know about yet.
Applied to both font and color, since both share the exact same
"resolve synchronously in createEditor(), return an inert
placeholder" shape and thus the exact same gap; font just hadn't been
reported.
Verified with the same standalone harness from the crash fix (real
QTreeView + DynamicTextItemDelegate + QAbstractItemView::edit()),
this time deliberately *not* sending the synthetic Enter keypress the
crash-fix verification needed: clicks the dialog's real OK button,
lets the event loop run, and confirms the picked color lands in the
model on its own. Also reconfirmed the crash fix itself still holds
(clean exit, no synthetic-Enter needed either way now) and did a full
Release build (504/504) with no new warnings.
Weekly cron replaced with a monthly run (1st of each month, 02:00 UTC)
to reduce unnecessary CI load.
retention-days raised from 14 to 40 across all six artifact uploads
(Qt5 + Qt6 tracks) to cover the new monthly interval with a safety
margin -- 14 days was shorter than the gap between two cron runs,
so the latest build's artifacts could expire before the next one
replaced them.
When multiple elements are pasted or moved in one batch, each call to
autoBreakConductors() now receives the shared state from the previous
call. This prevents two elements in the same batch from independently
claiming the same conductor, which would result in a double-delete on
redo().
Requested by ispyisail in PR review.
openTitleBlockTemplate needs a lambda: its matching overload has a default bool argument, so its pointer-to-member type
requires two parameters regardless of the default, while the signal provides only one -- no cast alone can both resolve the overload and
connect to a single-argument signal.
setAutoNum(QString)/setAutoNum(int,int) is a sender-side signal overload which needed a qOverload<QString> to match setFolioAutonum's
single-argument slot.
etc.), these three are ambiguous on the *slot* side:
activateProject(QETProject*)/activateProject(ProjectView*),
closeProject(ProjectView*)/closeProject(QETProject*), and
showError(const QETResult&)/showError(const QString&) each have two declarations on QETDiagramEditor. &QETDiagramEditor::activateProject
etc. alone won't compile with two candidates present; qOverload<T>() picks the one matching the actual signal's argument type, same as
the old SIGNAL()/SLOT() macro text did implicitly.
Default arguments aren't part of a function's pointer-to-member type, so &Class::slot has a type requiring the argument regardless of its
default value -- incompatible with a signal providing none, and &Class::slot alone won't compile against these signals at all.
When migrating to the modern member pointer connect, replaced with a lambda that calls the slot with no arguments, letting
the default apply exactly as before.
- SelectAutonumW::applyEnable(bool = true), connected to each NumPartEditorW's changed() signal in both setContext() and
on_add_button_clicked(). The corresponding disconnect() in on_remove_button_clicked() is removed rather than reimplemented: a
lambda-based connection can't be matched and removed by a separately-written disconnect() call, and the explicit disconnect
was already redundant -- the very next line deletes the part object, which Qt automatically disconnects on destruction (the same
guarantee setContext()'s own qDeleteAll() cleanup already relies on).
- PartText::adjustItemPosition(int = 0), connected to QTextDocument::contentsChanged().
- ExportDialog::slot_changeFilesExtension(bool = false), connected to ExportPropertiesWidget::formatChanged().
since QComboBox::activated(QString) still exists pre-Qt6 and makes &QComboBox::activated alone ambiguous:
- StyleEditor: outline_color/line_style/size_weight/filling_color,
both connect (activeConnections(true)) and disconnect
(activeConnections(false)) branches. antialiasing's stateChanged(int)
connect modernized alongside them (single signal, no disambiguation
needed).
- TitleBlockTemplateCellWidget: cell_type_input_ (two connects to
different slots), horiz_align_input_, vert_align_input_, logo_input_.
Also modernises QETApp's system tray connect.
In two cases stateChanged already replaced with version guarded checkStateChanged for future proofing.
setTransformOriginPoint() was only applied inside
parentElementRotationChanged(), so loading an already-rotated element,
or enabling keep_visual_rotation while rotation_point_center was
already true, left the origin at (0, 0) until the next parent rotation.
Apply the origin directly in both setters so it's always in sync.
Added .ts files (de and en) to the commit
QComboBox::currentIndexChanged(QString) still exists pre-Qt6.
TitleBlockTemplateLocationChooser: collections_ -> updateTemplates() (a virtual method; pointer-to-member dispatch still resolves to the
TitleBlockTemplateLocationSaver override at runtime as expected)
TitleBlockTemplateLocationSaver: templates_ -> updateNewName()
TitleBlockPropertiesWidget: m_tbt_cb -> changeCurrentTitleBlockTemplate(int)
XRefPropertiesWidget: m_type_cb -> typeChanged(), m_snap_to_cb ->enableOffsetSB(int), both connect (constructor) and disconnect(destructor)
Two QButtonGroup::buttonClicked overload-ambiguity fixes, plus cleanup of the connects sitting alongside them:
TitleBlockDimensionWidget: switched from the deprecated buttonClicked(int) id-based overload to buttonClicked(QAbstractButton*),
disambiguated via qOverload. The slot doesn't use the argument either way, so this is a pure modernization with no behavior change.
ExportPropertiesWidget: same buttonClicked fix for exported_content_choices, plus modernized the adjacent
currentIndexChanged(int) relay (disambiguated via qOverload, since QComboBox::currentIndexChanged(QString) still exists pre-Qt6) and
six QCheckBox::stateChanged(int) relays (single signal, no disambiguation needed).
QCheckBox::stateChanged(int) is deprecated as of Qt 6.7 in favor of checkStateChanged(Qt::CheckState), but this project has no Qt6 minor
version floor pinned in CMakeLists.txt, so stateChanged(int) remains the correct unconditional choice for now. QT_VERSION_CHECK(6, 7, 0) guarded
checkStateChanged was introduced to avoid future warnings.
Bug #331: "Il serait intéressant de pouvoir directement dans la fenêtre
'Sélection numérotation auto' modifier la valeur d'incrément et visualiser
la prochaine numérotation qui sera appliquée. Ceci sans être obligé
d'ouvrir la page de configuration."
The dock (AutoNumberingDockWidget) already let you see and edit a rule's
*current* value inline (added in 52c8ef6b4/031710b5f/ee4ba82d2). The
increment itself, and any preview of where the numbering is headed, was
reachable only through Configurer -> the full project-properties dialog.
Two new widgets per row (conductor/element/folio):
- An increment spin box, read from and written to the same NumerotationContext
field NumPartEditorW's increase_spinBox already edits in the full dialog --
same data, second place to reach it.
- A read-only next-value field, computed via
NumerotationContextCommands::next() -- the identical engine the "Suivant"
button in the full dialog already uses to step a whole context. Reusing it
rather than reimplementing the arithmetic means wrap-and-carry between parts
comes out identical to what actually happens when the number is next
consumed, and zero-padding matches real rendering
(NumerotationContext::formatValue(), mirroring
autonum::setSequentialToList()'s padding rule by hand since that function is
local to assignvariables.cpp).
NumerotationContext gains replaceIncrease(index, increase), a sibling to the
existing replaceValue() that touches only the increment field.
Every refresh call site in the file (13 of them) previously refreshed just the
value field; they now go through a new refreshRow(category), which refreshes
value + increment + next-value-preview together via a small per-row widget
bundle (rowFor()). This also let resetAutoNum()'s three-way switch collapse to
one line, and refreshValueFields()'s three near-identical blocks collapse to a
loop -- both existing before this change, not new here.
Verified live under Xvfb: created an element numbering rule "K" (Chiffre 1,
value 1, increment 1) via the full dialog, confirmed the dock showed
Valeur=1/Incrément=1/Suivant=2. Changed the dock's own Incrément to 3 --
Suivant updated live to 4, no dialog needed. Changed Valeur to 10 -- Suivant
became 13. Reopened the full configuration dialog and confirmed it read back
the same value_field=10/increase_spinBox=3, i.e. the round trip through
replaceIncrease()/storeContext() does not disturb type, initial value, modulus
or format.
Builds clean, CMake/Ninja Release, Qt 5.15, 820/820, no new warnings.
Fixes: https://qelectrotech.org/bugtracker/view.php?id=331
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bugtracker #308: the "current date" preset for a project's default
title block doesn't persist. A later comment on the report pinpointed
it exactly: the setting falls back to "No date" unless the folio tab
remains active when saving settings, and the same happens in Project
Properties.
TitleBlockPropertiesWidget::properties() (and its near-duplicate
sibling propertiesAutoNum(), copy-pasted with the same bug) reads the
date radio buttons like this:
else if (ui->m_current_date_rb->isVisible() && ui->m_current_date_rb->isChecked()) {
prop.useDate = TitleBlockProperties::CurrentDate;
...
Both the New Project settings page and Project Properties embed this
widget as one page of a QTabWidget (NewDiagramPage, in
configpage/configpages.cpp). QWidget::isVisible() depends on the
whole ancestor chain being visible, not just the widget's own state --
switch to any other tab before clicking OK/Apply and this radio
button's isVisible() goes false even though it's still checked
underneath, silently falling through all three branches. The function
returns a default-constructed TitleBlockProperties for the date
fields (useDate = UseDateValue, date = QDate(), i.e. "no date"),
matching exactly what was reported.
Fix: use isHidden() instead, which reflects only this widget's own
explicit state and mirrors the read side's own check in
setProperties()/initDialog() just above it in the same file -- that
side already uses isHidden(), not isVisible(), for the identical
"is the current-date option even offered here" question.
Verified directly: a standalone Qt program constructing the real
NewDiagramPage, checking "current date", switching the tab widget
away from Folio to Conducteur (reproducing the report's exact
trigger), then calling applyConf() and reading back the QSettings
value. Against the original code this saves date="null"; with the
fix, date="now" -- the same scenario, same tab switch, only the one
line differs. Also confirmed a full Release build (504/504, CMake/
Ninja, Qt 5.15.18) with no new warnings.
columns summed to exactly 100% (e.g. the shipped A4_1.titleblock), this produced qRound(NaN), which fatally aborted under Qt6's stricter qCheckedFPConversionToInteger assertion -- reached via
double-clicking a title block template to edit it.
Introduce TitleBlockTemplate::classifyWidthConstraint(), shared by minimumWidth() and maximumWidth(), returning std::optional WidthConstraintCase> to distinguish three non-finite outcomes:
Unconstrained (RTT columns == 100%, no absolute columns -- an ordinary, valid template), RelativeWidthExceeds100Percent (RTT alone exceeds 100%), and AbsoluteColumnsExceedRemainingWidth (RTT == 100%
with at least one absolute column also present) -- the latter two meaning the template's columns cannot be laid out at any width.
maximumWidth() previously only checked "are all columns absolute", which incorrectly reported "no upper bound" for the two unsatisfiable cases above; it now shares the same classification, so both functions
agree.
Update TitleBlockTemplateView::updateDisplayedMinMaxWidth() to show distinct, accurate tooltip text for all four cases instead of printing the old std::numeric_limits<int>::max()
sentinel or a misleading "no constraint" message for an unsatisfiable template.
Manually verified all four cases: a normal template (finite width), A4_1.titleblock (Unconstrained), an over-100% RTT template
(RelativeWidthExceeds100Percent), and RTT==100% with an absolute column present (AbsoluteColumnsExceedRemainingWidth).
Translations still partially missing.
plc-user