CALL

Syntaxe

myValue = CALL "myIndicator"[parameter1, parameter2]

Capturer plusieurs valeurs renvoyées :

myValue1, myValue2, myValue3 = CALL "myIndicator"[parameter1, parameter2]

Ignorer les valeurs dont on n'a pas besoin :

myValue1, ignored, myValue3 = CALL "myIndicator"[parameter1, parameter2]

Appliquer une constante de prix spécifique :

myValue = CALL "myIndicator"[parameter1, parameter2] (Close)

Paramètres

Comment ça marche

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 sert d'emplacement réservé pour les sorties dont l'appelant n'a pas besoin, ce qui garde l'affectation alignée sans inventer de variables jetables.

Une constante de prix facultative entre parenthèses contrôle à quelle série de prix l'indicateur appelé est appliqué. Si l'indicateur appelé calcule sur customclose en interne, spécifier (Close) ou une autre constante au point d'appel garde les deux scripts cohérents. L'omettre laisse en vigueur la valeur par défaut propre à l'indicateur appelé.

Chaque CALL évalue l'intégralité de l'indicateur appelé sur l'historique nécessaire pour répondre sur le bar courant. Les scripts qui appellent plusieurs indicateurs avec CALL, ou qui utilisent CALL dans des boucles, multiplient ce coût, ce qui est une cause fréquente de backtests lents. Lorsque la performance compte, intégrer directement de courtes formules dans le script appelant est souvent plus rapide qu'un CALL.

Exemples

Exemple 1, Appeler un indicateur personnalisé à deux paramètres (Indicateur)

// 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 a

L'indicateur personnalisé est évalué avec les deux paramètres fournis, et le script appelant divise le résultat par deux avant de le renvoyer.

Exemple 2, Signaux de trading issus d'un indicateur partagé (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
ENDIF

La stratégie utilise les deux sorties d'un indicateur personnalisé. Garder la logique de signal dans un seul indicateur fait que l'affichage graphique et la stratégie ne peuvent jamais diverger.

Exemple 3, Screening sur un oscillateur personnalisé (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")

Le screener réutilise un oscillateur personnalisé, ignore sa première sortie avec ignored, et fixe le prix appliqué à Close pour que les résultats correspondent à la version graphique.

Erreurs et pièges courants

• Le nom doit correspondre exactement. La chaîne entre guillemets doit reproduire précisément le nom de l'indicateur, espaces compris. Un indicateur renommé ou manquant casse tous les scripts qui l'appellent avec CALL.
• Nombre et ordre des paramètres. Les arguments entre crochets correspondent par position aux variables déclarées de l'indicateur. Des arguments trop peu nombreux, trop nombreux ou réordonnés produisent des valeurs erronées ou des erreurs de compilation.
• Coût en performance. Chaque CALL réévalue l'intégralité de l'indicateur appelé. Plusieurs CALL, ou un CALL vers un indicateur qui en appelle lui-même d'autres, peuvent ralentir considérablement les graphiques et les backtests.
• Prix appliqué incohérent. Si l'indicateur appelé utilise customclose, omettre la constante de prix au point d'appel peut appliquer silencieusement une série différente de celle de la version du graphique. Indiquez-la explicitement, par exemple (Close).

Instructions liées

• RETURN, définit les valeurs qu'un indicateur expose aux appelants.
• Close, constante de prix de clôture utilisable comme prix appliqué dans CALL.
• High, constante de prix haut utilisable comme prix appliqué.
• Low, constante de prix bas utilisable comme prix appliqué.
• CustomClose, séries de prix sélectionnables par l'utilisateur dans les indicateurs personnalisés.
• DEFPARAM, paramètres au niveau du script du programme appelant.