Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Le compilateur ne détecte pas l'absence du deuxième signe égal comme une erreur.
Ce n'est pas nécessaire, votre code ne contient pas d'erreur.
et il est identique à ce code.
Le compilateur ne détecte pas l'absence d'un deuxième signe égal comme une erreur.
Mais il donne un avertissement, au moins pour mon code comme ceci :
DealInfo.mqh' DealInfo.mqh 1 1l'expression n'est pas booléenne Shou History.mq5 60 19
0 erreur(s), 1 avertissement(s) 1 1
Ce n'est pas nécessaire, votre code ne contient pas d'erreur.
et c'est identique à ce code.
Et en vain, par exemple, le studio détecte ce code comme une erreur.
De plus, il semblerait que ce code
est identique à celui-ci :
Disons que 0 = faux, 1 = vrai, alors à quoi correspondent les autres chiffres ? 2,3,4, ...... :-)
À mon avis, cette approche ne mène à rien de bon et n'ajoute qu'une possibilité inutile de chercher l'erreur.
À mon avis, cette approche n'apporte rien de bon, elle ne fait qu'ajouter une occasion supplémentaire d'afficher l'erreur.
La raison de l'ajout d'une valeur non booléenne est que l'utilisateur peut voir ce qu'il fait.
Si je sauvegarde le jeu dans le terminal (sur la carte) et que je l'ouvre ensuite dans le testeur ou le terminal, tout va bien. Mais si je l'enregistre dans le testeur et que je l'ouvre ensuite dans le terminal, toutes les valeurs des variables de type non string s'affichent en abracadabra. Si je clique sur OK, lorsque j'ouvre à nouveau la fenêtre des paramètres, tout se passe bien, tous les paramètres sont remplacés par les nouveaux correctement, sauf les paramètres booléens. TOUT ce qui était troue devient falsa... Dans le testeur, le jeu sauvegardé depuis le testeur s'ouvre correctement.
Désolé pour le dérangement, le bug dont j'ai parlé plus tôt n'a toujours pas été corrigé. Lors de l'exécution de l'indicateur donné dans la description de la fonction CopySpread , l'historique des écarts est dessiné avec un trou. Le trou couvre toujours la période allant du début du terminal au début de l'indicateur. Il semble que les spreads provenant du serveur à chaque nouveau tick ne soient pas enregistrés dans l'historique des spreads.Merci !
Je reçois des avertissements du compilateur :
Conversion implicite enum
perte éventuelle de données due à la conversion de type
lorsque vous utilisez cette chaîne :
Qu'est-ce qui ne va pas ici ?
J'ai trouvé : vous devez utiliser de longues
Puis une autre question. Cette construction fonctionnera-t-elle correctement
lorsque posType est défini comme long ?
Je reçois des avertissements du compilateur :
Conversion implicite enum
perte éventuelle de données due à la conversion de type
lorsque vous utilisez cette chaîne :
Qu'est-ce qui ne va pas ici ?
J'ai trouvé : vous devez utiliser de longues
Puis une autre question. Cette construction fonctionnera-t-elle correctement
lorsque posType est défini comme long ?
Désolé pour le dérangement, le bug dont j'ai parlé plus tôt n'a toujours pas été corrigé. Lors de l'exécution de l'indicateur donné dans la description de la fonction CopySpread , l'historique des écarts est dessiné avec un trou. Le trou couvre toujours la période allant du début du terminal au début de l'indicateur. Il semble que les spreads provenant du serveur à chaque nouveau tick ne soient pas enregistrés dans l'historique des spreads.Merci !