VersionNavigationHelper.hpp referenced by codegen but never created
Table of Contents
This page is a capture in the discarded bucket of the product backlog.
Resolved (PR #1567, task Update ores.cpp.qt codegen templates for the generic HistoryDialog): the has_version_navigation branch's wireVersionHistory<>=/=VersionNavigationHelper.hpp reference was replaced entirely with the fullHistory-parameter approach CurrencyController already proved out (PR #1553/#1563) — the version-nav toolbar's full-history optimisation is now sourced from the same fetch<Entity>History wrapper that resolves the generic HistoryDialog's signals, not a separate, never-implemented helper. No entity needs the has_version_navigation: false workaround anymore.
What
projects/ores.codegen/library/templates/cpp_qt_controller.cpp.mustache
has a has_version_navigation feature (a version-nav toolbar with
first/prev/next/last, wired via a wireVersionHistory<> template
function) that #include=s =ores.qt/VersionNavigationHelper.hpp and
calls wireVersionHistory<>, but that header does not exist anywhere
in the repository. Discovered while regenerating calendar with
has_version_navigation: true (matching currency's own setting) —
the build failed with fatal error: 'ores.qt/VersionNavigationHelper.hpp'
file not found. currency's own generated CurrencyController.cpp
predates this template feature and was never regenerated since, so
nobody had hit this until now. Worked around by setting
has_version_navigation: false on calendar for the time being.
Either implement VersionNavigationHelper.hpp (with the
wireVersionHistory<> template function the mustache template
expects), or remove the has_version_navigation feature from the
template until it's actually built.
Why
Any entity regenerated with has_version_navigation: true will fail
to compile until this is fixed — a latent trap for the next
ores.codegen.entity entity or entity generate re-run that touches
this flag.
References
projects/ores.codegen/library/templates/cpp_qt_controller.cpp.mustache— lines ~21-23 and ~438-451, the twohas_version_navigationgated blocks.projects/ores.refdata/modeling/ores.refdata.calendar.org— worked around here withhas_version_navigation: false.
See also
- Model calendars as proper ORE Studio reference data — where this was discovered.