Skip to content
AmiBroker TA Course

AFL Alerts

An alert is the point where your research stops being a study and starts being a commitment. Up to now every formula in this course has answered a question you asked it. An alert answers a question you are not asking, at a moment you did not choose, and it interrupts whatever you were doing to do so. That changes the standard it has to meet.

The engineering problem in this part is not “how do I make AmiBroker beep”. That takes one line. The problem is that an alert which fires four hundred times is worse than no alert at all, because after the eighth one you stop reading them, and the ninth was the one that mattered. Everything here is aimed at a single, unglamorous property: the alert fires when the thing happens, once, and stays quiet otherwise.

What this part covers

Section titled “What this part covers”

Three pages, and they build on each other.

The first takes AlertIf() apart argument by argument. It has six parameters, four of which people routinely get wrong, and it contains an internal state machine that the official function reference warns about in capital letters. You will also meet the Alert Output window, the sound and e-mail paths, the external-program path and its caveats, and — just as important — the places where an alert you wrote will silently produce nothing at all because of a checkbox in Preferences.

The second is where Part 9’s distinction between a state and an event stops being a programming nicety and starts costing you your attention. A state condition is true on every bar of a run; an alert wired to one has no idea it already told you. This page covers the four independent layers of defence — events instead of states, ExRem(), the completed-bar guard, and AmiBroker’s own repeat suppression — and, more usefully, gives you a procedure for proving that a specific alert fires exactly once instead of hoping so.

The third is a project: a breakout alert with a session window, a volatility buffer and a once-per-session latch, plus an offline test harness that establishes how many times it should have fired before you trust it to tell you how many times it did.

The rule this part will not break

Section titled “The rule this part will not break”

The course ends at alert, human review, decision. There is no automated order placement here, and there will not be any later. That is a deliberate boundary, not a gap in coverage: automated execution changes what a defect costs from “I missed a trade” to “I lost money while I was asleep”, and it belongs to a different body of engineering practice — order state reconciliation, fail-safes, broker connectivity monitoring, kill switches — that this course does not teach and should not pretend to.

You will find the mechanisms that other people build automation on top of, described honestly, including the ones with sharp edges. What you do with them afterwards is yours.

You do not need a subscription for any of this

Section titled “You do not need a subscription for any of this”

Every page in this part is completable on end-of-day data, in either edition, with no data subscription. AlertIf() is not one of the Professional-only functions, it does not require a streaming plugin, and it works on stored history exactly as it works on a live feed.

That matters more than it sounds. The behaviour that makes alerts hard — repeat firing, intrabar flicker, the last bar changing under you — can all be reproduced on historical bars using Bar Replay, which truncates the database at a moving playback position and re-runs every formula as it advances. Bar Replay is a better test rig than a live market anyway, because you can run the same twenty minutes of tape ten times and get the same answer, and you can do it on a Sunday.

The one thing a live feed adds is genuinely live intrabar behaviour, and each page says plainly where that is the case and what to do instead.

What you need first

Section titled “What you need first”

Part 9 for Cross(), ExRem() and the state-versus-event distinction; Part 12 for the Analysis window and its four modes; Part 20 if you intend to alert on intraday data, because a session filter written against the wrong time-stamping convention fails in a way that looks like a working alert. Part 26 covers Bar Replay in its own right — this part uses it as a tool and tells you the handful of controls you need.

Part25 of 36Level5 — Real-Time AmiBroker UserPages3Estimated time1.8 hours

1 of 3 pages in this part need the Professional edition or a live data feed, marked below. Every one of them has a Level A path that uses Bar Replay and historical data instead, so the part can be completed in full without a subscription.

0 / 3 lessons in this part completed