State Migration On Upgrade Template

Any tool that saves state between runs - trade counters, running totals, a high-water mark - eventually needs to add a new field to that state without breaking every user who upgrades from an older version. The naive answer is to just start reading the new field and hope it is there; the first time it is not, the tool either crashes or silently treats a missing value as zero in a place where zero has real meaning. This template stores its example state (a demo trade counter, last event time, running P/L, and a high-water equity mark) as a small VERSION=n header followed by KEY=VALUE lines in MQL4\Files. Every OnInit reads that version and compares it to CURRENT_STATE_VERSION, the version this build of the code actually understands. If the file is older, a chain of small MigrateVxToVy() functions runs in order, each one responsible for exactly the fields introduced at that step, with an explicit and documented default rather than a guess - RunningPnl defaults to zero because a v1 file never tracked it at all, while HighWaterEquity is seeded from the account's current equity rather than zero, because zero would render as a fabricated total-loss drawdown the moment the panel first repaints. The other direction matters just as much and is easy to get wrong: if the file on disk is NEWER than this build - the classic case of rolling back to an older executable after a user has already run a newer one - this template does not try to strip or guess at fields it does not recognise. It sets a safe-mode flag, alerts once, and refuses to touch the file at all for the rest of the session, so a downgrade never destroys data a newer version already wrote. Every migration also writes a versioned backup of the pre-migration file before overwriting it, so the original is recoverable by hand even if a migration step turns out to be wrong. Notes and limitations - This is a template - the trade counter, last-event time, running P/L, and high-water equity fields are a stand-in demo schema, not real trading statistics; it places no orders. Replace ToolState with a real project's own fields. - The migration chain only moves forward, one version at a time. There is no "migrate directly from v1 to v3" shortcut and none is needed - each step only ever adds what that specific version introduced, kept simple and auditable one field at a time. - A version gap in the chain (a MigrateVxToVy step that was never written for some x) stops the chain short and leaves the state at the last version it could reach, logged plainly - it does not guess forward. - Safe mode is intentionally read-only for the whole session once triggered, including the periodic timer save; the only way out is to restart with a build whose CURRENT_STATE_VERSION is high enough, or to manually inspect and edit the file. - Backups accumulate one file per migration ever performed (name.vN.bak) and are never cleaned up automatically - delete old ones from MQL4\Files by hand if disk clutter becomes a concern.

Expert advisor · MT4 · v1.0 · Free

Tags: Alerts · MT4 Expert Advisor · MQL4 Source Code

Expert advisors (EA) for MT4 & MT5 · PolyMaria