Grouped Config Transactions

Setting configuration values one at a time is fine until a batch of related changes needs to move together - update a risk percentage and a max-spread filter as one logical change, for instance - and the second value in the batch turns out to be wrong. Applying each Set() call directly as it is made leaves the config in a half-updated, inconsistent state exactly when it matters most: right after the user edited several related settings at once. GctBegin/GctStage/GctCommit stage a batch of key/value changes without touching anything, then run a full validation pass before writing a single value. Two things abort the WHOLE transaction with the config completely untouched: a staged key that does not already exist in the target config (the common typo- in-a-setting-name case, caught instead of silently creating a new, never-read key), and the same key staged twice in one batch (ambiguous intent - rather than silently taking "last write wins," the whole batch is rejected so the caller has to be explicit). Only once every staged change passes does the second, apply pass run - by that point nothing can fail partway through. The transaction operates on the caller's own parallel keys[]/values[] string arrays, so it works with whatever config storage a project already uses - GlobalVariable-backed, file-backed, or purely in memory - without imposing a particular persistence mechanism. Notes and limitations Values are always stored and staged as plain strings - this header does not type-check or range-check a value against what the setting is supposed to mean (a number, a bool, an enum); that validation is the caller's responsibility before or after commit. A transaction holds at most GCT_MAX_PENDING (64) staged changes; GctStage returns false without staging anything once that cap is reached, so check its return value if a batch could plausibly exceed it. GctCommit's duplicate-key check is O(n^2) over the staged count, which is negligible at the 64-entry cap this header enforces but is not intended for a much larger transaction size. requireExistingKey defaults to true (reject unknown keys) precisely because that is the safer default for a settings store; pass false explicitly on any transaction that is meant to introduce brand-new keys.

Script · MT5 · v1.0 · Free

Tags: MT5 Script · MQL5 Source Code

MQL4 & MQL5 scripts · PolyMaria