CALL
CALL runs a user-defined indicator from ProBuilder code and returns its values. Reuse custom indicator logic inside indicators, strategies and screeners.
Syntax
myValue = CALL "myIndicator"[parameter1, parameter2]Capturing multiple returned values:
myValue1, myValue2, myValue3 = CALL "myIndicator"[parameter1, parameter2]Skipping values that are not needed:
myValue1, ignored, myValue3 = CALL "myIndicator"[parameter1, parameter2]Applying a specific price constant:
myValue = CALL "myIndicator"[parameter1, parameter2] (Close)Parameters
| Name | Type | Default | Description |
|---|---|---|---|
| indicator name | string | required | Exact name of the user-defined indicator, in quotes. |
[p1, p2, ...] | list | none | Arguments passed to the indicator's declared variables, in order. |
| price constant | keyword | indicator default | Optional applied price such as Close, High, or Low, in parentheses after the brackets. |
How it works
CALL bridges scripts. A custom indicator built in the indicator editor exposes whatever its RETURN statement emits, and any other script can pull those values in with CALL instead of duplicating the logic. Changes to the shared indicator then propagate to every caller automatically.
The values listed in brackets are bound, in order, to the indicator's declared parameters, so their count and meaning must match what the indicator expects. When the indicator returns several values, the left-hand side lists one variable per returned value in the same order as the RETURN statement. The keyword ignored acts as a placeholder for outputs the caller does not need, which keeps the assignment aligned without inventing throwaway variables.
An optional price constant in parentheses controls which price series the called indicator is applied to. If the called indicator computes on customclose internally, specifying (Close) or another constant at the call site keeps the two scripts consistent. Omitting it leaves the called indicator's own default in force.
Each CALL evaluates the entire called indicator over the history needed to answer for the current bar. Scripts that CALL several indicators, or CALL inside loops, multiply that cost, which is a common cause of slow backtests. Where performance matters, inlining short formulas into the calling script is often faster than a CALL.
Examples
Example 1, Calling a two-parameter custom indicator (Indicator)
// Fetch the value of a personal indicator with parameters 7 and 14
myValue = CALL "my Personal Indicator Name"[7, 14]
// Post-process the result before plotting
a = myValue / 2
RETURN aThe custom indicator is evaluated with the two supplied parameters, and the calling script halves the result before returning it.
Example 2, Trading signals from a shared indicator (ProOrder)
DEFPARAM CumulateOrders = false
// The custom indicator "TrendGauge" returns a trend line and a signal flag
trendLine, signalFlag = CALL "TrendGauge"[20, 2]
// Enter long when the shared indicator flags a signal above its trend line
IF signalFlag = 1 AND close > trendLine THEN
BUY 1 CONTRACT AT MARKET
ENDIF
IF signalFlag = -1 THEN
SELL AT MARKET
ENDIFThe strategy consumes both outputs of a custom indicator. Keeping the signal logic in one indicator means the chart display and the strategy can never drift apart.
Example 3, Screening on a custom oscillator (ProScreener)
// Only the second output of "DualOscillator" is needed here
ignored, oscValue = CALL "DualOscillator"[14, 3] (Close)
// Keep instruments where the custom oscillator signals oversold
SCREENER[oscValue < 20] (oscValue AS "Oscillator")The screener reuses a custom oscillator, skips its first output with ignored, and pins the applied price to Close so results match the chart version.
Common errors and gotchas
- Name must match exactly. The quoted string must reproduce the indicator's name precisely, including spaces. A renamed or missing indicator breaks every script that CALLs it.
- Parameter count and order. The bracketed arguments map positionally onto the indicator's declared variables. Too few, too many, or reordered arguments produce wrong values or compilation errors.
- Performance cost. Each CALL re-evaluates the whole called indicator. Multiple CALLs, or a CALL to an indicator that itself CALLs others, can slow charts and backtests dramatically.
- Applied price mismatch. If the called indicator uses
customclose, omitting the price constant at the call site can silently apply a different series than the chart version. State it explicitly, for example(Close).
Related instructions
RETURN, defines the values an indicator exposes to callers.Close, closing price constant usable as an applied price in CALL.High, high price constant usable as an applied price.Low, low price constant usable as an applied price.CustomClose, user-selectable price series inside custom indicators.DEFPARAM, script-level parameters of the calling program.
