MQL4 Code Flow in Expert Advisors, Indicators, and Scripts: Stop Treating Them Like They're the Same Thing

If you've ever opened the MetaEditor and started writing an MQL4 program, you've probably asked yourself: what's the real difference between an Expert Advisor, an indicator, and a script? They all look like C, they all compile to EX4, and they all run on a chart—so does it actually matter which one I pick?

The short answer is yes. And the longer answer involves understanding the execution model, event handling, and lifecycle of each program type—differences that determine whether your code runs once, runs forever, or runs every time the market blinks.

The contrast is most obvious when you compare three use cases: a script that closes all open positions, an indicator that plots a moving average, and an EA that manages a trailing stop. The script runs and exits. The indicator waits for ticks, recalculates, and redraws. The EA waits for ticks, evaluates entry logic, and sends orders. Same language, completely different runtime behavior.

---

MQL4 Program Types and Their Execution Models

The MQL4 reference defines three executable program types: Expert Advisors, custom indicators, and scripts. Each has a distinct purpose and a distinct code-flow pattern.

Scripts are single-execution programs. You attach them to a chart, they run the OnStart() function exactly once, and then they're unloaded. They're useful for one-time operations: open a batch of orders, close all positions, delete pending orders, or modify stop-loss levels across multiple symbols. The entire code executes immediately, without waiting for a new tick. Once finished, the script is gone from the chart.

Custom indicators are tick-driven programs designed for analysis, not trading. When attached to a chart, an indicator runs its initialization function (OnInit()) and then recalculates at every tick via the OnCalculate() function. The indicator's job is to compute values and display them visually—lines, histograms, arrows, or buffers. Indicators cannot trade. They cannot send orders, modify positions, or access trading functions. They are strictly analytical.

Expert Advisors are also tick-driven, but their purpose is automation and trade management. Like indicators, an EA is attached to a chart and runs in response to ticks—but unlike indicators, EAs can place orders, modify stops, close positions, and manage risk. An EA runs continuously until it's removed from the chart or the terminal shuts down.

The critical distinction in code flow: a script runs its entire logic once and stops. An indicator and an EA run repeatedly, triggered by market events—but the indicator recalculates visual data, while the EA executes trading logic.

---

The Event-Driven Reality: Why Code Flow Isn't Linear

The execution model in MQL4 is fundamentally different from procedural C programming. In a script, code flow is linear—you write instructions, they execute in order, and the program exits. In an EA or indicator, code flow is event-driven.

The runtime environment doesn't call your program continuously. Instead, it calls specific pre-defined functions when certain events occur:

• OnInit() — called when the program is attached to a chart or the terminal starts
• OnDeinit() — called when the program is removed or the terminal shuts down
• OnTick() — called on every new tick (EAs and scripts, though scripts rarely use it)
• OnCalculate() — called on every tick for indicators, with price data passed as parameters
• OnTimer() — called at a user-defined interval
• OnChartEvent() — called when chart events occur (key presses, mouse clicks, object changes)

This is where the practical difference emerges. An EA's code flow isn't "do A, then B, then C." It's "wait for a tick, run OnTick(), return control to the terminal, and wait again." If a new tick arrives while OnTick() is still executing, that tick is discarded—the program doesn't process it until the current run completes.

This has real consequences for strategy logic. If your EA processes orders and calculations inside OnTick(), but your code takes longer than the interval between ticks, you'll start missing ticks and your logic will lag behind market conditions. That's why many EA developers structure their code with time-based filtering—checking whether a new bar has formed before executing logic, rather than processing every single tick.

---

Indicators: The Price-Data Pipeline

Indicators handle code flow differently. When OnCalculate() is called, it receives arrays of price data (Open[], High[], Low[], Close[], TickVolume[], Volume[], and Spread[]) along with two critical integers: rates_total and prev_calculated.

The prev_calculated parameter tells the indicator how many bars were already processed in the previous call. This allows efficient incremental calculation—recalculate only the new bars, not the entire chart history. That's why well-written indicators are fast even on large data sets. They don't reprocess everything on every tick.

This also means indicators have a built-in optimization path that EAs lack. An indicator's code flow can branch between "calculate from scratch" and "calculate only new data" using prev_calculated, reducing CPU load significantly. EA developers don't have a similar built-in mechanism—they have to implement their own batching logic if they want to avoid processing every tick.

---

EA vs Script: The AutoTrading Factor

Scripts ignore the AutoTrading button. They run regardless of whether AutoTrading is enabled or disabled. EAs respect the AutoTrading state. If AutoTrading is off, an EA's OnTick() handler still runs—but any trade orders sent through functions like OrderSend() will fail.

This is a subtle but important code-flow difference. A script can close all positions with AutoTrading off? Yes—because closing is a trading operation, but AutoTrading controls whether the terminal allows EA-generated trade instructions. Scripts are manual tools, not automated systems, so they're not subject to the same restriction. But if you try to close a position from an EA with AutoTrading disabled, the order fails with an error.

---

The Practical Problem: Monitoring Without the Desktop Overhead

Here's a scenario many traders face: you're running an EA on MT4, but you don't want the platform window visible on your screen all day. You minimize it, but it's still in the taskbar. You need to check whether your EA is running, whether your open positions are profitable, and whether the latest price moved in your favor—but opening the full MT4 window is disruptive to your workflow.

This is where Camovia Tray addresses a specific pain point in the EA workflow. The app turns MT4 into a tray tool—letting you check live quotes and open positions directly from the system tray without restoring the MT4 window[citation:PRODUCT_KNOWLEDGE]. For traders running EAs that need continuous monitoring, this means you can quickly glance at your positions, see unrealized P&L, and know whether your automated strategy is performing as expected—all without interrupting your other work[citation:PRODUCT_KNOWLEDGE].

The key feature here is position visibility without terminal restoration. When an EA manages your trades, you still need to know the state of those positions. Opening the full MT4 window breaks focus and draws attention—especially in shared workspaces. Camovia Tray's floating order panel shows your open positions, along with the ability to close a position with a click if you need to intervene manually[citation:PRODUCT_KNOWLEDGE].

For traders writing scripts that perform one-time actions—closing all positions, for example—the ability to see the outcome without opening MT4 is equally practical. You don't need the full terminal to verify that your script executed correctly. A glance at the tray panel tells you what's still open[citation:PRODUCT_KNOWLEDGE].

The data stays local. No quotes or position information leave your computer[citation:PRODUCT_KNOWLEDGE]. This aligns with the expectation that your EA's logic and your account data remain private—especially when you're running third-party EAs that you haven't fully audited.

---

Data Source: MT4 vs MT5 Bridge

For the purposes of MQL4 development, it's worth noting that Camovia Tray supports both MT4 and MT5. For MT4, it uses a one-time bridge EA (CamoviaBridge) to read position and quote data[citation:PRODUCT_KNOWLEDGE]. This bridge is attached to a chart, runs within the MT4 environment, and exposes the data to the tray tool. For MT5, the connection is direct, without requiring a bridge[citation:PRODUCT_KNOWLEDGE].

This means when you're developing and testing MQL4 EAs, the bridge EA doesn't interfere with your main EA's logic—it runs alongside it, reading data without sending orders or modifying positions[citation:PRODUCT_KNOWLEDGE]. Your strategy executes as usual, and the tray tool provides a monitoring layer that's completely separate from the trading logic.

---

Code Flow Lessons for MQL4 Developers

Understanding the execution model influences how you structure your MQL4 programs:

1. Scripts — use for one-time manual interventions. No event handling complexity, no persistent state. Run once and exit.

1. Indicators — use for analytical display. Leverage prev_calculated for performance. Avoid trading functions—they're blocked by the runtime.

1. EAs — use for automation. Understand the tick-driven model. Implement bar-change detection if you don't need every tick. Respect AutoTrading state. Add proper error handling because order functions can fail due to market conditions, connectivity, or AutoTrading state.

The code-flow framework pattern shown in open-source MQL4 projects—where EA logic runs only on new bars rather than every tick—is a practical solution to the tick-overload problem. This approach reduces CPU usage, makes backtesting more consistent, and simplifies debugging because you're evaluating fewer state transitions.

For traders who rely on third-party EAs, understanding whether the code is designed for tick-level precision or bar-level strategy informs how often you need to monitor it. A high-frequency scalper processing every tick requires different oversight than a daily-bar trend-following EA. Camovia Tray's tray-based monitoring works for both—you get the position snapshot regardless of the EA's time horizon[citation:PRODUCT_KNOWLEDGE].

---

The Takeaway

MQL4 code flow isn't just an academic detail—it shapes how you build, test, and run each type of program. Scripts run once. Indicators recalculate on every tick but can't trade. EAs run on every tick and can trade, but their execution depends on AutoTrading state and the event queue. Knowing these differences helps you choose the right tool for the job and avoid the pitfalls of porting logic from one type to another without adjusting the execution model.

And if you're running EAs that need attention throughout the day, the ability to monitor positions and quotes without the MT4 window consuming your screen—that's where a lightweight tray tool bridges the gap between running automated strategies and staying aware of what they're doing.