[Bug]: S-Curve chart signature exceeds the 255-character formula text limit

[BekbolatBK]

ProjectEngine version

v1.2.5

Excel version and language

Microsoft Excel LTSC, MSO version 2608 (build 16.0.20326.20072), 64-bit, Russian UI

Affected area

S-Curve

Expected result

Update S-Curve completes without a STOP, and the chart source signature is stored in the hidden defined name so that a later run can skip an unnecessary chart rebuild.

Actual result

A STOP is raised:

VBA error in Run_SCurve_Engine
-> check the last edited block in mod_SCurve
-> Text values in formulas are limited to 255 characters
   (localized message, Excel run-time error 1004)

Important: the S-Curve itself is fully built. tbl_SCURVE is populated and cht_SCurve is drawn correctly. The failure happens after that, in SCurveStoreChartSignature.

Because the defined name is never created, SCurveStoredChartSignature() always returns an empty string, so every run rebuilds the chart from scratch and ends with the same STOP.

Reproduction steps

1. Open the v1.2.5 workbook.
2. On the WBS sheet enter five rows:
   • 1 / Test project (summary, no dates)
   • 1.1 / Task A - weight 40, baseline start 02/03/2026, duration 10
   • 1.2 / Task B - predecessor 1.1, weight 35, duration 8
   • 1.3 / Task C - predecessor 1.2, weight 25, duration 6
   • 1.4 / Finish - Task Type Milestone, predecessor 1.3
3. Click Update Planning. It completes with Calculation completed successfully.
4. Click Update S-Curve.
5. The SCURVE sheet and the chart are built correctly, and then the STOP appears.

No actual dates, no progress, Latin task names, one month of schedule - the smallest case that still reproduces.

Anonymized example or screenshots

Root cause. SCurveStoreChartSignature stores the signature in a workbook-level defined name:

refersToValue = "="""" & Replace(signature, """", """""") & """""
Set nm = ThisWorkbook.Names.Add(Name:=SCURVE_CHART_SIGNATURE_NAME, RefersTo:=refersToValue)

A defined name stores a formula, and a string literal inside a formula is limited to 255 characters.

The signature is assembled by SCurveChartSourceSignature from seven parts, each built by SCurveRangeSignature:

SCurveRangeSignature = columnName & ":" & rng.rows.Count & ":" & _
    rng.Address(RowAbsolute:=True, ColumnAbsolute:=True, ReferenceStyle:=xlA1, External:=True)

External:=True embeds the workbook file name in brackets - seven times. Example fragment:

Date:29:[Book.xlsm]SCURVE!$A$3:$A$31|Daily Actualized:29:[Book.xlsm]SCURVE!$D$3:$D$31|...

Measured signature lengths (computed from the actual column names, row counts and address forms):

workbook	S-Curve rows	signature length
minimal example above	29	509
larger schedule	560	537
ProjectEngine.xlsm	560	432
short file name PE.xlsm	29	341
empty file name (theoretical floor)	29	292

Even with an empty file name and the smallest possible dataset the signature is 292 characters, so the 255 limit is exceeded unconditionally whenever the workbook contains data. On an empty workbook the problem is invisible only because Run_SCurve_Engine returns through SCurve_SafeEmptyState before reaching the signature.

Additional context

Suggested fix. Store a fixed-length key instead of the concatenated addresses - for example a CRC/FNV hash of the same string. That keeps the cache semantics and removes the dependency on file name length and row count. Alternatively store the signature in a hidden worksheet cell via .Value (32,767-character limit) rather than in a defined name.

Scope check. Reproduced directly on the v1.2.5 release asset (Excel/ProjectEngine_v1.2.5.xlsm) with the five-row example above: the S-Curve sheet and chart are built correctly and the STOP appears immediately afterwards. SCurveRangeSignature and SCurveStoreChartSignature are also byte-identical in Excel/ProjectEngine.xlsm at commit 9e66bc8, verified by extracting the VBA project from both workbooks.

Possible reason this has not been reported before (hypothesis, not verified). The failure was observed on an LTSC/perpetual build. If current Microsoft 365 builds accept a longer string constant in Names.Add ... RefersTo, the defect would stay invisible there while failing on every perpetual build, since the signature is over the limit by construction.

Thank you for publishing this project - the architecture guide made it possible to locate the cause quickly.

Submission checks

• I tested the latest available release.
• I removed confidential and company-specific information.
• I searched existing Issues and Discussions for the same problem.