Iceberg Order Manager

Posting the whole size of a large pending order shows the whole intention at one price level. This header instead posts a fixed-size visible clip; when that clip triggers, it immediately posts a fresh clip for whatever volume is still outstanding, at the same price, until the total requested volume has been filled. Only one clip is ever live at a time. The trap most naive versions of this fall into is fill detection. On MQL4, scanning the pending order pool by position to see whether "the order is still there" breaks the moment the pool re-indexes, which happens on every single change to it - this header instead re-selects the clip's own ticket by SELECT_BY_TICKET on every update, since a pending order that triggers keeps its ticket number and simply changes OrderType() to OP_BUY or OP_SELL. On MQL5 the trap is different but just as real: pending orders and positions live in two separate pools with no ticket-for-life model at all, so a triggered clip's own ticket disappears from the active pool the instant it fills - the MQL5 version follows that same ticket number into history and reads ORDER_POSITION_ID off it to tell a genuine fill apart from a cancellation, rather than watching a type flag that no longer applies. See MQL4 VERSUS MQL5 DIFFERENCES for the full detail. Every clip is normalised to the broker's lot step, minimum and maximum before it is sent, and the money-per-point figure the header can report is always derived from the symbol's real tick value and tick size, scaled by the lots actually filled - never a hardcoded per-lot number, so it holds on metals, indices and JPY crosses as well as plain FX pairs, on both platforms. The header is self-contained on each platform. No external dependencies, no DLLs - a small state struct per job and plain functions you call from a script or an EA's OnTick. The MQL5 version additionally uses CTrade from the standard library, which ships with every terminal and does not break self-containment. Notes and limitations - Only one clip is ever live per job. If you need several iceberg jobs running at once (different symbols or opposite directions), call Iceb_Create once per job and keep the returned job ids separately. - A pending order that expires or is deleted by hand without triggering ends the job without filling that clip - Iceb_Update treats this as "cannot continue safely" rather than guessing whether to resume, since resuming could double a manual cancellation the trader intended. - The header keeps job state in module-level arrays for the lifetime of the chart/script. It is not persisted to disk, so a terminal restart loses in-flight job bookkeeping even though any already-filled positions remain open exactly as they are on the trade server. - Slippage/deviation, stop loss and take profit are fixed for a job's whole life - every clip is sent with the same values passed to Iceb_Create. - Neither version tracks the ticket of the position a clip's fill creates - filled volume is recorded, but ongoing management of the resulting position (trailing, closing) is left to the caller. This mirrors the original MQL4 design rather than adding scope the header never had. - This is visible-size slicing for a retail terminal, not genuine market microstructure concealment - it controls what your own order book shows, not what any other participant's feed shows.

Script · MT4 · v1.0 · Free

Tags: Volume · Pending Orders · MT4 Script · MQL4 Source Code

MQL4 & MQL5 scripts · PolyMaria