Trade Batch Executor

Any EA that opens more than one order at a time - a grid EA opening several legs, a basket hedger balancing across symbols, a news straddle placing several pending orders around one event - fires a run of OrderSend() calls with no shared bookkeeping between them. If item 3 of 6 fails, most hand-rolled loops either carry on silently with no record of the gap, or abort mid-batch leaving an inconsistent, half-built position with no cleanup and no list of what actually went through. This header collects every result explicitly. CTradeBatchExecutor.Add() queues plain order-request structs; Execute() runs them all under one of two policies chosen up front - BATCH_ABORT_ON_FAILURE stops queuing further items the instant one fails and marks the rest as skipped, BATCH_CONTINUE_ON_FAILURE runs every item regardless and reports the full picture at the end. Each item's SBatchResult records whether it succeeded, its ticket, the final error code, how many attempts it took, and whether it was skipped by an abort - enough for the caller to reconcile exactly what happened without re-deriving it from the order pool afterward. Each item independently retries the classic transient trade errors (requote, off-quotes, trade context busy, timeout, price changed, broker busy, too frequent requests) up to a configurable retry count with a wait between attempts, waiting out IsTradeContextBusy() before every attempt rather than failing immediately on contention from another EA in the same terminal. A permanent error (invalid stops, not enough money, trade disabled) is not retried - retrying those wastes time and API calls for no possible different outcome. Notes and limitations - A batch is not atomic. BATCH_CONTINUE_ON_FAILURE can leave the account in a partially-filled state by design - that is the whole point of the policy - and even BATCH_ABORT_ON_FAILURE cannot undo an item that already succeeded before the failing one was reached. Reconciling a partial batch (closing what already opened) is the caller's responsibility, using the returned SBatchResult array. - Stop loss and take profit are supplied as POINT distances from the fill price, not absolute prices, so the same request struct works sensibly whether the fill price is known in advance (a limit/stop order) or only resolved at send time (a market order). - Each item's retry policy is shared across the whole batch (SetRetryPolicy), not configurable per item - a batch needing different retry behaviour per leg should be split into separate CTradeBatchExecutor instances. - One CTradeBatchExecutor instance is meant for one batch. Call Clear() (or construct a new instance) before building the next batch.

Script · MT4 · v1.0 · Free

Tags: Grid · Hedging · News Trading · Pending Orders · MT4 Script · MQL4 Source Code

MQL4 & MQL5 scripts · PolyMaria