Erreurs, bugs, questions - page 492
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
Absolument, exactement sur tous les points.
Autant qu'il était possible de le faire, autant il a été reçu. C'est comme ça qu'il faut le comprendre. Vérifiez la profondeur de l'historique disponible. Assurez-vous que les données sont disponibles avant de les demander. Quelle version avez-vous ? J'ai récemment corrigé un bogue avec la copie d'images mensuelles, cela pourrait être le cas.
Il n'est donc pas bien vérifié ou le conseiller expert n'est PAS multidevise, il peut juste fonctionner sur différents symboles. Le raisonnement est simple - savoir que les tics viennent sur des symboles différents à des moments différents. Par conséquent, si un conseiller expert est surTick EURUSD (par exemple), et qu'il vérifie le tick GBPUSD ou même seulement les changements de tick au lieu de EURUSD, le résultat sera différent. En particulier, une barre formée sur EURUSD peut se produire avant la formation d'une barre avec le même temps sur GBPUSD. Si vous tradez la paire GBPUSD deux fois sur la même barre : la barre GBPUSD précédente sera toujours considérée comme une nouvelle barre (zéro). Quant aux indicateurs multidevises, tout est clair. Apprenez les bases.
C'est quoi ce putain de calcul, un tick est entré sur 1 paire, mais si le second tick est en retard et f...
c'est-à-dire que nous avons besoin du prix au moment de l'apparition d'une nouvelle barre et des ticks.
Il ne joue pas un rôle dans l'apparition d'une nouvelle barre à tous les symboles, mais il est de
La stratégie dépend, si vous n'êtes pas un scalper
Je voudrais demander à nouveau à l'équipe MQ s'il est prévu de mettre la fonction iCustom() en état de fonctionnement.
À l'heure actuelle, les développeurs d'Expert Advisor ne peuvent pas offrir une solution universelle utilisant iCustom(),
où le client peut spécifier le nom d'un indicateur externe utilisé par le conseiller expert.
Pour cela, le client doit disposer du code source de l'Expert Advisor, ainsi que saisir manuellement chaque nom d'indicateur dans le code de l'Expert Advisor, ce qui est assez peu pratique, pour ne pas dire plus.
Il y a aussi le problème de l'indication explicite obligatoire de la valeur des cellules tampons indicatrices.
Si aucune valeur (vide ou non vide) n'est explicitement assignée aux cellules tampons de l'indicateur dans le texte de l'indicateur, la fonction iCustom() peut remplir les cellules indiquées dans le Conseiller Expert avec
avec n'importe quel déchet. Je pense qu'un tel fonctionnement de la fonction ne peut être considéré comme correct.
Je voudrais demander une fois de plus à l'équipe MQ s'il est prévu de mettre la fonction iCustom() en état de marche.
À l'heure actuelle, les développeurs d'Expert Advisor ne peuvent pas offrir une solution universelle utilisant iCustom(),
où le client peut spécifier le nom d'un indicateur externe utilisé par le conseiller expert.
Pour ce faire, le client doit disposer du code source de l'Expert Advisor, ainsi que saisir manuellement chaque nom d'indicateur dans le code de l'Expert Advisor, ce qui est assez peu pratique, pour ne pas dire plus.
Vous pouvez passer un nom dynamique de l'indicateur appelé dans iCustom, mais le jeu de paramètres de chaque indicateur personnalisé est différent.
Malheureusement, nous ne connaissons pas de solution universelle à la question "comment pouvons-nous implémenter en toute sécurité l'appel sans toucher au code, sans savoir ce qu' il sera appelé et avec quels paramètres?
Si je comprends bien, vous voulez créer un système de plugin, lorsqu'un utilisateur tiers définit un nom d'indicateur avec des paramètres (par exemple, "MyIndicator(10,20,50,100)") dans les paramètres de l'EA. Pour un tel cas avec un format rigide du nom, vous pouvez analyser vous-même la chaîne de caractères, former un bloc de paramètres et implémenter un appel dynamique de iCustom avec un ensemble différent de paramètres en tant que classe d'enveloppe. En d'autres termes, plusieurs variantes de l'appel iCustom avec différents jeux/nombre de paramètres seront cachées à l'intérieur.
Il y a également un problème d'indication explicite obligatoire de la valeur des cellules tampon de l'indicateur.
Si aucune valeur (vide ou non vide) n'est explicitement assignée à la cellule tampon de l'indicateur dans le texte de l'indicateur, la fonction iCustom() peut remplir les cellules indiquées dans le Conseiller Expert avec
avec n'importe quel déchet. Je pense qu'un tel fonctionnement de la fonction ne peut être considéré comme correct.
C'est de l'impudence et de la paresse pure et simple de la part du développeur de ne pas remplir le tampon qui lui a été donné à son entière disposition.
Le système d'exécution ne sait pas comment vous utilisez la mémoire tampon de l'indicateur et n'a pas le droit de la remplir avec certaines valeurs, surtout pendant les moments de surallocation massive (pagination ou mise à jour du graphique). L'indicateur est nécessairement informé de tous les cas où un recalcul est nécessaire par la fonction OnCalculate(...,const int prev_calculated,...) et le paramètre prev_calculated.
Dans iCustom, vous pouvez passer un nom dynamique de l'indicateur à appeler, mais chaque indicateur personnalisé a son propre ensemble de paramètres.
Malheureusement, nous ne connaissons pas de solution universelle à la question "Comment pouvons-nous implémenter l'appel en toute sécurité sans perturber le code, sans savoir ce qui sera appelé et avec quels paramètres?
Si je comprends bien, vous voulez créer un système de plugin, lorsqu'un utilisateur tiers définit un nom d'indicateur avec des paramètres (par exemple, "MyIndicator(10,20,50,100)") dans les paramètres de l'EA. Pour un tel cas avec un format rigide du nom, vous pouvez analyser vous-même la chaîne de caractères, former un bloc de paramètres et implémenter un appel dynamique de iCustom avec un ensemble différent de paramètres en tant que classe d'enveloppe. En d'autres termes, plusieurs variantes de l'appel iCustom avec différents jeux/nombre de paramètres seront cachées à l'intérieur.
Par la nécessité problématique de modifier le code, je voulais dire l'obligation de spécifier explicitement le nom de l'indicateur lors des tests.
dans le format #property tester_indicator "Name.ex5", mais pas un nombre différent de paramètres de l'indicateur.
Les indicateurs peuvent être utilisés avec les paramètres par défaut, en sélectionnant uniquement le nombre de tampons indicateurs avec le signal correspondant.
C'est de l'impudence et de la paresse pure et simple de la part du développeur de ne pas remplir le tampon qui lui a été donné à son entière disposition.
Le système d'exécution ne sait pas comment vous utilisez la mémoire tampon de l'indicateur et n'a pas le droit de la remplir avec certaines valeurs, surtout pendant les moments de surallocation massive (pagination ou mise à jour des graphiques). L'indicateur est nécessairement notifié de tous les cas de nécessité de recalcul via la fonction OnCalculate(...,const int prev_calculated,...) et le paramètre prev_calculated.
Est-il vraiment difficile d'assigner Empty_Value aux cellules inutilisées dans iCustom() au lieu de les encombrer avec des déchets de la pile ?
https://www.mql5.com/ru/forum/1111/72233#comment_72233
Notez que la valeur réelle des cellules tampons reste un Vide. C'est la fonction iCustom() qui effectue les manipulations.
Par nécessité problématique de changements dans le code, je voulais dire la nécessité de spécifier explicitement le nom de l'indicateur pendant les tests.
dans le format #property tester_indicator "Name.ex5", mais pas un nombre différent de paramètres de l'indicateur.
Nous allons résoudre la question plus avant - il y a des nuances.
Est-il vraiment difficile d'assigner Empty_Value aux cellules inutilisées dans iCustom() au lieu de les remplir avec des déchets de la pile ?
https://www.mql5.com/ru/forum/1111/72233#comment_72233
Cela ne devrait pas être fait. Relisez ma réponse, s'il vous plaît.
La raison pour laquelle iCustom() attribue des valeurs arbitraires à ces cellules tampons qui ne sont en fait remplies de rien n'est pas claire pour moi, de même que la raison pour laquelle cela ne peut être évité d'aucune manière.
Je suppose que cela a quelque chose à voir avec l'allocation de mémoire pour le tableau de données correspondant du tampon indicateur.
Une telle opération de iCustom(), alors qu'il est impossible de déterminer l'origine et la véracité des données, me semble inadmissible et crée des risques supplémentaires pour l'utilisateur.
Si iCustom() attribue de toute façon des valeurs arbitraires et incohérentes avec les valeurs réelles aux cellules tampons,
pourquoi n'assigne-t-il pas des valeurs égales à Empty_Value à ces cellules comme cela est implémenté dans MT4 ?
Au moins, leur statut serait clair.
mais de cette façon
il y a un arrondi, est-ce que ça dit toujours ça ?
Je ne discute pas.
mais de cette façon
l'arrondi est toujours écrit, cela devrait-il être comme ça ?