Crash Sentinel

MQL4 has no event for "the terminal was killed" or "the power went out mid-session" - a genuine crash leaves nothing to catch. What it does leave behind is an absence: whatever a clean OnDeinit would have done did not happen. This header turns that absence into something checkable. A small sentinel file is written when the program starts (Arm(), call from OnInit) and deleted again when it stops for a reason that genuinely means the user asked it to stop (Disarm(reason), call from OnDeinit, and only actually deletes on REASON_REMOVE, REASON_CHARTCLOSE or REASON_CLOSE). If the file is STILL there the next time the program starts, the previous run either crashed, was killed, or stopped for a reason this header deliberately does not treat as final. That "deliberately" is the judgment call worth stating plainly: reasons like REASON_RECOMPILE, REASON_PARAMETERS, REASON_CHARTCHANGE, REASON_TEMPLATE and REASON_ACCOUNT all fire OnDeinit, but they are immediately followed by a fresh OnInit in the SAME terminal session - the program has not actually stopped, it is reloading. Disarming the sentinel on those reasons would hide a genuine crash landing in the narrow gap right after a reload. The trade-off is an honest one: a bare recompile or an input edit will, once, cause the very next OnInit to report "the previous run was not confirmed clean" even though nothing actually crashed. That false positive is documented here rather than engineered away, because the alternative (treating every deinit reason as final) is the version that actually hides crashes. Notes and limitations - The sentinel file must have a name unique to the running instance if more than one copy of the same program can run at once (multiple charts, multiple magic numbers) - include the symbol/timeframe/magic in the filename, the same way any sandboxed file needs a caller-chosen unique name. - As explained above, REASON_RECOMPILE / REASON_PARAMETERS / REASON_CHARTCHANGE / REASON_TEMPLATE / REASON_ACCOUNT do not disarm the sentinel by design - a bare recompile or input edit will report the prior run as "not confirmed clean" on the very next start. This is a deliberate honest trade-off, not a bug: see the full description above. - Detects the SHUTDOWN gap only. It cannot tell you what state the program was in when it stopped (open positions, pending state) - only that the stop was not confirmed clean. Recovery logic based on that signal is the caller's responsibility. - Stored in the standard MQL4 sandbox (MQL4\Files), not the common folder - this is about one terminal's own chart, not cross-terminal coordination. - No money is at risk in the demo. It writes and deletes only its own sentinel file and never sends an order.

Script · MT5 · v1.0 · Free

Tags: Trading Sessions · MT5 Script · MQL5 Source Code

MQL4 & MQL5 scripts · PolyMaria