Erreurs, bugs, questions - page 2342
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
Dans ce sens, MT4 était beaucoup plus sage que MT5 - il n'y avait pas de plantage de programme et vous pouviez analyser le LastError.
Premièrement : continuer à exécuter le programme après une erreur critique irrécupérable n'est pas de la sagesse, mais de la stupidité.
Deuxièmement : Je n'ai pas obtenu PrintError() dans MetaTrader 4 765x32 après l 'avoir exécuté.
Troisièmement : Si on enlève strict, il l'a atteint, mais GetLastError() retourne 0, donc on ne sait pas quoi analyser
Comment avertir l'utilisateur de l'arrêt de l'EA ?
Dans ce sens, MT4 était beaucoup plus sage que MT5 - il n'y avait pas de crash du programme et vous pouviez analyser le LastError.
Et lorsqu'on accède à un tableau, n'est-il pas logique de vérifier l'indice d'accès ?
Premièrement : c'est de la stupidité, et non de la sagesse, de continuer à exécuter le programme après qu'une erreur critique irrécupérable se soit produite.
Deuxièmement, après avoir exécuté ceci dans MetaTrader 4 765x32, PrintError() ne s'est jamais produit.
Troisièmement, si vous supprimez strict, il renvoie 0, mais GetLastError(), donc on ne sait pas trop ce qu'il faut analyser.
La tâche n'était pas de montrer que MT4 est meilleur que MT5. Je devais résoudre un problème pratique.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Bibliothèques : HistoryTicks
fxsaber, 2018.12.10 13:55
Obtenir un message indiquant que l'EA s'est arrêté en raison d'un tableau hors de portée(pas la faute de l'auteur de l'EA). Par exemple, en raison d'un manque de mémoire ou d'une autre défaillance. Cela signifie que vous saurez tout de suite que l'EA s'est arrêté anormalement, plutôt que de le remarquer accidentellement quelques heures plus tard.
Il est désagréable de constater que le conseiller expert s'est arrêté, mais cela n'est signalé d'aucune manière.
Et lorsqu'on accède à un tableau, ne serait-il pas logique de vérifier l'indice d'accès ?
Ce n'est pas logique.
Il est donc d'autant plus raisonnable de condenser les données transmises.
Vérifié, 60Mb est facilement écrit (MT4/5) aux ressources. Donc s'il y a une limite, elle est plus élevée.
Un petit point, mais quand même.
Lors de l'envoi vers le stockage - le premier panneau "Fixation" - fonctionne bien, et le second, la confirmation, dans mon premier cas, n'attend pas la touche OK, mais sort immédiatement, et deuxièmement - il ne montre pas tous les fichiers envoyés. Je l'ai pourtant vérifié - les fichiers sont envoyés normalement.
C'est juste moi ?
Cela semble correct - après l'envoi, une liste des fichiers envoyés s'affiche avec une confirmation que tout s'est bien passé.
Ça n'a pas de sens.
Et pourquoi ?
Il me semble que nous n'avons pas besoin de vérifier l'index dans les endroits où, logiquement, il est impossible qu'un index qui dépasse les limites du tableau puisse apparaître. Et même dans ce cas, vous devriez utiliser ASSERT, juste au cas où.
Et dans les endroits où l'index dépend d'actions précédentes liées à des paramètres externes, des citations et des actions de l'utilisateur, la vérification de la référence à l'index devrait être obligatoire.
A votre avis, ce n'est pas le cas ?
Et pourquoi ?
Il me semble qu'il n'est pas nécessaire de vérifier l'index lorsque, selon la logique du programme, il est impossible qu'un index apparaisse en dehors du tableau.
Je suis d'accord.
Et même dans ce cas, vous devrez utiliser ASSERT au cas où.
Je ne suis pas d'accord car la lisibilité du code en souffrira beaucoup.
Aux endroits où l'indice dépend d'actions antérieures concernant des paramètres externes, des devis et des actions de l'utilisateur, le contrôle de l'indice de manipulation doit être obligatoire.
Je ne comprends pas ce que l'on entend ici par paramètres externes. Chaque fois que vous vérifiez que ArrayResize ou ArrayCopy se sont terminés normalement et qu'il n'y a pas de mémoire triviale qui s'épuise, cela va gonfler le code à travers ASSERT, et c'est vraiment le bordel. Si vous ne le vérifiez pas, vous obtiendrez un arrêt imperceptible du conseiller expert. Jusqu'à présent, je n'ai trouvé qu'une seule solution : remplacer ArrayResize et ArrayCopy.
Qui est sur le chemin ?
ChartSaveTemplate(chart_id,"\\Files\\MyPreferredTemplates\\cewl.tpl");
La fonction ne crée pas de dossier, elle écrit seulement un modèle si un dossier existe déjà ..... Si le dossier n'existe pas, erreur 4112
Les dossiers doivent donc être préparés à l'avance...
C'est intéressant, la fonction FileOpen ne peut pas créer un dossier dans le dossier du modèle et la fonction ChartSaveTemplate ne crée pas de répertoires...
En d'autres termes, si vous souhaitez enregistrer des modèles dans des sous-dossiers, créez des dossiers manuellement.....
plus de mémoire
lors de la recherche de GlobalVariables
peut survenir ?
C'est une situation étrange avec KB.
- Disons que j'ai publié un code dans KB en russe.
- Je peux seulement l'éditer, le mettre à jour, mettre une nouvelle version dans la version en langue russe
- quand la traduction de ce code dans d'autres langues apparaît, alors l'édition n'existe pas pour moi dans ces langues.
Il s'avère que si je mets régulièrement à jour et améliore le code en russe, pour les autres langues ces mises à jour ne se font pas automatiquement et elles ne sont pas disponibles.
Je viens de voir que la version anglaise d'un de mes codes dans KB est très dépassée, et je n'ai pas accès à la mise à jour.
Pourquoi ne pas au moins mettre à jour le code automatiquement dans les autres langues ? Il est clair que la condition pour faire une telle chose devrait être d'exiger des commentaires en anglais uniquement.