Erreurs fréquentes en ProBuilder et leur correction (ProRealTime)

Les erreurs fréquentes en ProBuilder sont écrites noir sur blanc dans le manuel officiel de ProRealTime, version 6.1.0 du 1er décembre 2025 : relu page par page, il compte seize mises en garde. Les unes tiennent à l’écriture : un caractère accentué hors d’un commentaire, un ENDIF oublié, un RETURN mal placé. Les autres viennent du langage, qui relit le code à chaque barre.

Quelles erreurs le manuel ProBuilder signale-t-il lui-même ?

Seize, de la page 4 à la page 47 : d’abord l’écriture, puis la mémoire des variables, puis le calcul.

Quelles erreurs d’écriture le manuel ProBuilder demande-t-il d’éviter ?

Cinq : les caractères spéciaux, les instructions collées, le ENDIF manquant, le RETURN mal placé et le DEFPARAM tardif. La première surprend les francophones. « N’utilisez pas les caractères spéciaux (exemples : é, ù, ç, ê, -, _, &…) dans ProBuilder », écrit le manuel page 31, en précisant que cela ne s’applique pas aux commentaires. Un commentaire est une ligne précédée de //, que le programme ne traite pas : vos notes gardent leurs accents, vos noms de variables y renoncent.

Le manuel rappelle, page 4, d’insérer un espace entre chaque instruction. Et quand on place un IF dans un autre, il demande, page 19, autant de ENDIF que de IF : toute condition ouverte se referme.

Restent les deux places obligées. RETURN, l’instruction qui affiche le résultat, a d’après le manuel « des propriétés particulières qu’il faut connaître pour éviter certaines erreurs de programmation » : elle s’utilise une seule et unique fois, à la dernière ligne. Pour afficher plusieurs résultats, on ne la répète pas ; on les sépare par une virgule, RETURN a,b. L’instruction DEFPARAM se place à l’inverse obligatoirement au début.

DEFPARAM CALCULATEONLASTBARS = 200
// ce programme retourne la moyenne mobile arithmétique de période 20 sur le prix de clôture
RETURN Average[20](Close)

D’après le manuel ProBuilder, page 31 : trois lignes du manuel, réunies ici. Code non exécuté dans la plateforme.

Une bonne nouvelle, page 6, compense ces rigueurs : ProBuilder ne distingue pas les majuscules des minuscules, et IF peut s’écrire iF sans dommage.

Pourquoi une variable ProBuilder revient-elle à sa valeur de départ à chaque barre ?

Parce que le code est relu en entier à chaque barre, ligne d’initialisation comprise. Le manuel le rappelle page 28 : le langage lit le code autant de fois qu’il y a de barres. Écrire Count = 0 en tête de programme, c’est donc vider à chaque passage la variable Count, cette boîte qui porte un nom. L’instruction ONCE règle l’affaire : elle n’est traitée que la première fois qu’elle est rencontrée.

ONCE Count = 0
ONCE i = 0
IF i <= 5 THEN
    Count = Count + i
    i = i + 1
ENDIF
RETURN Count

D’après le manuel ProBuilder, page 28, « Programme 2 ». Code non exécuté dans la plateforme.

Le manuel donne les deux résultats : sans les deux ONCE, ce programme retourne 0 ; avec eux, 15.

Quelles erreurs ProBuilder touchent l’historique des variables et les tableaux ?

Trois : vouloir réécrire le passé, chercher le passé d’un tableau, et confondre les crochets, qui comptent des barres, avec les parenthèses, qui comptent des jours. Une variable ProBuilder garde sa valeur à chaque chandelier, et MaVariable[3] lit celle d’il y a trois chandeliers. Lire, pas écrire : « il est impossible de modifier le passé », dit le manuel page 7. La remarque dépasse un peu la programmation.

Un tableau, lui, est une variable à plusieurs cases, reconnaissable à son symbole $. Il n’est pas historisé : on ne récupère pas la valeur qu’avait une case sur un chandelier antérieur. Autre piège, page 44 : quand vous remplissez la case n, ProBuilder met des zéros dans les cases précédentes restées vides. Ces zéros ne sont pas considérés comme définis ; la fonction IsSet retourne 1 si la case a été définie, 0 sinon.

Comment éviter une division par zéro ou une boucle infinie en ProBuilder ?

En testant le cas avant le calcul, et en donnant toujours une sortie à la boucle. Une boucle répète des instructions, avec FOR ou WHILE ; BREAK en force la sortie. Page 25, le manuel s’en sert quand le plus haut égale le plus bas, juste avant de diviser par leur différence :

// Si high - low, on sort de la boucle pour éviter une division par zéro.
IF high[i] = low[i] Then
    BREAK
ENDIF
osc = (close - low) / (high - low)

D’après le manuel ProBuilder, page 25 : extrait d’une boucle WHILE. Code non exécuté dans la plateforme.

Pour les boucles, la consigne tient en une phrase, page 27 : toujours s’assurer d’avoir une condition de sortie valide, pour éviter les boucles infinies. Le manuel ajoute, pages 23 et 24, qu’il faut éviter les boucles lorsque d’autres solutions existent : Return Average[5](High) remplace toute une boucle et s’exécute beaucoup plus rapidement.

À quoi sert la constante Undefined en ProBuilder ?

À ne rien afficher plutôt qu’à afficher un chiffre faux. Le manuel la définit page 13 : Undefined est une donnée indéfinie, l’équivalent d’une case vide, qui indique à l’indicateur de ne pas afficher de résultat pour certaines variables. Son exemple, page 23, l’attribue à une moyenne tant que l’historique ne compte pas assez de barres.

Quelles erreurs ProBuilder concernent les dates et les unités de temps ?

Quatre : une date mal écrite, une heure mal écrite, Day pris pour Days, et un TIMEFRAME qui vise trop bas. Une date est un seul nombre de huit chiffres, 20200704 pour le 4 juillet 2020 ; une heure en a six, 160000 pour 16 heures.

TIMEFRAME fait travailler un code sur une autre unité de temps que celle du graphique, à deux conditions données page 41 : qu’elle soit supérieure, et qu’elle en soit un multiple. Sur un graphique 10 minutes, on peut appeler 20 minutes, 1 heure ou 1 jour, pas 5 minutes ni 17 minutes. Et, page 43, une variable calculée dans une unité de temps ne peut pas être écrasée par un calcul dans une autre.

Ces erreurs se provoquent sans risque sur un compte démo.

Ouvrir un compte démo gratuit

Questions fréquentes sur les erreurs en ProBuilder