OnTimer versus OnTick for a scalping EA

[Fairman]

OnTimer versus OnTick for a scalping EA

Most MQL EAs put everything in OnTick, because that's what the templates do. For a scalping EA I'd split the work between OnTick and OnTimer, and being clear about why.

OnTick runs when a new tick arrives on the chart symbol. That's the right place for anything that reacts to price: checking whether an entry condition is met, managing a stop, reading the spread at the moment of entry.

OnTimer runs on a schedule you set with EventSetTimer, in seconds, or EventSetMillisecondTimer. It runs whether ticks arrive or not. That makes it the right place for anything tied to the clock rather than price. Closing all trades at a fixed session end time. Checking a news calendar file. Writing a heartbeat to a log so you know the EA is alive. Scanning other symbols that aren't on the chart.

The classic bug of putting time based logic in OnTick is that it only runs when a tick arrives. On a quiet pair late in the day, ticks can be several seconds apart, so a close at exactly 16:00 might happen at 16:00:07. Usually harmless. During the rollover hour, with ticks very sparse, it can be much later.

Kill the timer in OnDeinit with EventKillTimer. Forgetting it is a common source of strange behaviour after reloading the EA.

[Fairman]

In the strategy tester, OnTimer is simulated, and the accuracy depends on the tick model you test with. With every tick based on real ticks it behaves sensibly. With open prices only, timer events can line up oddly with bar opens, and time based exits may look better or worse than they would live. If your EA depends heavily on the timer, test it on real ticks before trusting the results. It's slower, but the alternative is a backtest that quietly assumes timing you won't get in live trading. A short comparison run on both models for the same week shows how big the gap is for your EA.

[Fairman]

There's only one timer per EA in MQL5. If you need several things at different intervals, say a heartbeat every 30 seconds and a symbol scan every second, set the timer to the shortest interval and keep counters inside OnTimer to run each task when its turn comes. Trying to call EventSetTimer again with a different value just replaces the old one. This catches people who copy timer code from two different examples into one EA and then wonder why one of the tasks never runs at all. A comment at the top of the handler listing each task and its interval keeps it readable later.

[Fairman]

Heavy work in either handler blocks the other. MQL runs event handlers one at a time per EA, so if OnTimer spends two seconds reading a large file, any ticks that arrive in that time are queued, and in MQL5 only the latest one is kept for OnTick when it frees up. For a scalper that can mean missing the exact tick you wanted to react to. Keep both handlers short and move anything slow, like file parsing or web requests, into its own small step that runs rarely. A straightforward timer at the start and end of each handler, printed to the log, shows where the time goes.

[Fairman]

A practical pattern for multi symbol scalpers is to drive all symbol checks from OnTimer at a short interval, say 200 to 500 milliseconds, and ignore OnTick except for the chart symbol. That way the EA reacts on every symbol at roughly the same speed, instead of being fast on the chart pair and slow on the others. The cost is a bit more CPU. On a VPS running a few EAs it's rarely a problem, but check the load if you run a lot of charts on a small machine. Starting at 500 milliseconds and only going faster if needed is a sensible default.

[FXS HongKong Scalper]

One trap with OnTimer is that it does not run when the terminal is busy or the EA is still inside an earlier OnTimer call. Events do not stack, so if one call takes longer than the timer interval, the next one is simply skipped. That is easy to miss if the handler does network calls or file writes. It shows up most during busy moments such as the Tokyo open, when ticks arrive fast and OnTick work slows everything. Logging the time each OnTimer call actually starts is a quick way to see whether the planned interval holds.