Repository navigation
fix: Keep starting address 0 in 0-based projects (#142) - #143
Merged
Merged
Conversation
DataViewDefinitions::normalize() clamped PointAddress to a minimum of 1, which is only correct for 1-based projects. With a 0-based address base a data view starting at address 0 was saved as PointAddress="0" but loaded back as 1, because normalize() runs from the XML reader. normalize() no longer touches PointAddress; FormDataView clamps the value against the current address range when the definition is applied, so 1-based projects still fall back from 0 to 1. The legacy 1.x loaders can now parse PointAddress normally instead of re-reading it after normalize(). Add regression tests for the 0-based round trip and for the 1-based fallback.
sanny32
self-requested a review
November 4, 2026 13:40
sanny32
approved these changes
Nov 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #142. With a 0-based address base, a data view whose starting address is
0was saved correctly (PointAddress="0"in the project file) but showed1after reopening the project, so address 0 could not be persisted.Root cause
DataViewDefinitions::normalize()clamped the address unconditionally:PointAddress = qMax<quint16>(1, PointAddress);That clamp is only valid for 1-based projects. With a 0-based base the valid range starts at 0 (
ModbusLimits::addressRange(space, /*zeroBased*/ true)), butnormalize()is base-agnostic and is called by the XML reader, so0was destroyed on every load. The legacy 1.x loaders worked around this by re-reading the rawPointAddressattribute afternormalize().Changes
src/displaydefinition.h:normalize()no longer touchesPointAddress; the lower bound depends on the address base, which this struct does not know.src/formdataview.cpp:setDisplayDefinition()andsetDisplayDefinitionSilent()clamp the starting address against the current address range before applying it, so 0-based projects keep0while 1-based projects still fall back from0to1.src/legacyprojectloader.cpp,src/legacyprojectparser.cpp: parsePointAddressnormally and drop the now-unneeded re-read workaround.src/tests/test_appproject.cpp: two regression tests.Tests
preservesZeroBasedStartingAddressZeroAcrossReopen: a 0-based data view starting at address 0 survives two save/reload cycles, including the register values at address 0 (fails without the fix).clampsZeroStartingAddressForOneBasedProject: a 1-based project file containing the invalidPointAddress="0"still opens at address 1.preservesZeroBasedStartingAddressAcrossReopen(issue Starting Address decreasing on save with 0-based addressing #130), legacy parser tests and the rest ofomodsim_tests_appprojectpass.