Erreurs, bugs, questions - page 3121
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
Arrêtez de vous arracher les cheveux à cause du faible classement de vos ...codes. Si une personne donne à votre code une note de 1, cela ne signifie pas qu'il est ce qu'il est. Eh bien, refaites-le au moins 100 fois... et les 100 fois, ce code sera noté de cette façon. Est-ce si difficile à comprendre ?
Peut-être que votre CV reflète la réalité du vote et c'est triste. Mais je ne suis pas triste pour moi - ces étoiles virtuelles ne peuvent pas être bues avec du thé et mises dans mon portefeuille, je suis frustré par le concept de la façon dont les produits sont présentés aux nouveaux utilisateurs, en m'inquiétant spécifiquement pour eux. En l'absence de notation crédible, les utilisateurs ne seront tout simplement pas en mesure de rechercher efficacement le produit qu'ils souhaitent sur la base du critère "tri par notation". Il s'avère que le système d'évaluation est un système vide et qu'il faut chercher le bon produit en fonction de son nom et de sa description plutôt que de se fier au nombre inutile d'étoiles. Sinon, ils vont continuer à pêcher des trucs... ce qui flotte à la surface (à juste titre ou non) et ce dont ils ont vraiment besoin sera négligé. Je suggérais juste que cela devrait être modifié pour être plus réfléchi. Mais si personne ne veut combattre cette réalité, je m'en lave les mains.
Votre résumé reflète peut-être la réalité du vote, et c'est décevant. Mais ce n'est pas moi qui suis triste - ces étoiles virtuelles ne peuvent pas être bues avec du thé et mises dans mon portefeuille, je suis déçu par le concept de la manière dont les produits sont présentés aux nouveaux utilisateurs, en m'inquiétant précisément pour eux. En l'absence de notation crédible, les utilisateurs ne seront tout simplement pas en mesure de rechercher efficacement le produit qu'ils souhaitent sur la base du critère "tri par notation". Il s'avère que le système d'évaluation est un système vide et qu'il faut chercher le bon produit en fonction de son nom et de sa description plutôt que de se fier au nombre inutile d'étoiles. Sinon, ils vont continuer à pêcher des trucs... ce qui flotte à la surface (à juste titre ou non) et ce dont ils ont vraiment besoin sera négligé. Je suggérais juste que cela devrait être modifié pour être plus réfléchi. Mais si personne ne veut combattre cette réalité, je m'en lave les mains.
Jetons un coup d'oeil à votre code.
Chaque tick déclenche l'accès aux variables globales, 4 requêtes à la fois.
Il en découle que vous NE POUVEZ PAS utiliser ce code sur votre machine personnelle, vous pouvez l'utiliser ailleurs, là où vous n'épargnez pas votre disque dur.
Dans une boucle, pendant la recherche, ArraySize devrait être appelé 3 fois , alors qu'il y en a deux, c'est une charge supplémentaire sur le processeur, c'est aussi indésirable, les performances du code baissent.
DeInite supprime les objets d'une manière étrange, il n'y a rien de mal ici, mais c'est un mauvais exemple pour les débutants, si vous le faites normalement, vous devriez entrer un préfixe lors de la création des objets etles supprimer sans recalculs excessifs.
Je donne 2 points pour votre code.
Pour le travail de l'indicateur - je ne sais pas, je ne l'ai pas exécuté.
Objectif ?
Bien, jetons un coup d'oeil à votre code.
A chaque tick, l'accès aux variables globales est déclenché, 4 requêtes à la fois.
Il en découle que vous NE POUVEZ PAS utiliser ce code sur votre machine personnelle, vous pouvez l'utiliser ailleurs, là où vous n'épargnez pas votre disque dur.
Dans une boucle, pendant la recherche, ArraySize devrait être appelé 3 fois , alors qu'il y en a deux, c'est une charge supplémentaire sur le processeur, c'est aussi indésirable, les performances du code baissent.
DeInite supprime les objets d'une manière étrange, il n'y a rien de mal ici, mais c'est un mauvais exemple pour les débutants, si vous le faites normalement, vous devriez entrer un préfixe lors de la création des objets etles supprimer sans recalculs excessifs.
Je donne 2 points pour votre code.
Pour le travail de l'indicateur - je ne sais pas, je ne l'ai pas exécuté.
Objectif ?
1. À chaque tick, il y a un appel au GP, donc à chaque tick, et aussi à chaque réinitialisation (par exemple, les transitions par les TF) le code principal et plus lourd dansOnCalculate() n'est pas exécuté, et l'indicateur fonctionne plus rapidement. Le calcul de nouvelles données - seulement avec l'apparition d'une nouvelle barre basse D1, ce qui est beaucoup plus rare, que sur chaque tick.
2. J'ai travaillé de manière réfléchie et approfondie sur le code, mais j'ai laissé certaines opérations de comparaison inutiles dans if() parce que je suis sûr que cela n'affectera pas les performances.
3. A propos du MUST not be, c'est très exagéré. Vous pouvez le télécharger et voir par vous-même : l'indicateur vole.
4. Je ne savais pas que les GP étaient téléchargés sur l'AF et qu'ils étaient lus au même endroit chaque fois qu'on y accédait dans une session MT5 en cours. Je continue à penser qu'ils sont lus du LCD vers la RAM une fois lorsque je démarre le terminal et qu'ils y vivent, et que l'indicateur y accède en RAM, et non sur le LCD.
5. Je ne pense pas que ArraySize() soit une fonction coûteuse. Et même s'il est cher, vous ne le remarquerez pas dans ce code particulier. J'optimiserais probablement cette fonction dans mon premier indicateur où elle est utilisée assez souvent, alors que l'indicateur lui-même est beaucoup plus complexe et gourmand en ressources.
6. Dans OnDeinit() j'utilise :
où juste là est supprimé par le préfixe " l " (les noms " label" et " line" ont été utilisés lors de la création des objets.
7. Vous avez maintenant fait ce qu'un utilisateur qui a téléchargé et compris le code devrait faire. Vous avez trouvé les failles - cela fait aussi partie de l'apprentissage de MQL.
8. Bottom line : 1.) mon argument principal du code non-idéal de cet indicateur - simplicité, compacité et vitesse... plus un travail parfait ; 2.) mon deuxième argument principal du code imparfait - le manque d'analogues, même mauvais, en termes de vitesse et de polyvalence (voir la discussion sur les originaux des autres) et la disponibilité des améliorations par rapport à l'original, qui, soit dit en passant, est étroit et n'est pas plié en boucles compactes en termes de grand nombre de blocs répétés de manière similaire.
9. Malgré le point 7, vous n'avez pas vraiment compris le code de quelqu'un d'autre. Votre score de 2 est trop faible. Je ne vous recommande pas encore d'évaluer les logiciels par leur code. Je ne parlerai pas d'objectivité car il est impossible d'en attendre d'un seul utilisateur. Une estimation objective (cote) n'est possible qu'en tant que somme des estimations de plusieurs utilisateurs sains d'esprit et elle ne doit certainement pas être nécessairement élevée.
1. À chaque tick, il y a une référence au GP, de sorte qu'à chaque tick, ainsi qu'à chaque réinitialisation (par exemple, les transitions par les TF), tout le code principal et plus lourd dansOnCalculate() n'est pas exécuté, et l'indicateur fonctionne plus rapidement. Le calcul de nouvelles données - seulement avec l'apparition d'une nouvelle barre basse D1, ce qui est beaucoup plus rare, que sur chaque tick.
2. J'ai travaillé de manière réfléchie et approfondie sur le code, mais j'ai laissé certaines opérations de comparaison redondantes dans if() parce que je suis sûr que cela n'affectera pas les performances.
3. A propos du MUST - très exagéré. Vous pouvez télécharger et voir par vous-même que l'indicateur vole.
4. Je ne savais pas que les GP étaient vidés sur le disque dur et lus à partir de celui-ci à chaque fois qu'on y accédait dans une session MT5 en cours. Je continue à penser qu'ils sont lus du HD vers la RAM une fois lorsque je démarre le terminal et qu'ils y vivent, et que l'indicateur y accède en RAM, et non sur le HD.
5. Je ne pense pas que ArraySize() soit une fonction coûteuse. Et même s'il est cher, vous ne le remarquerez pas dans ce code particulier. J'optimiserais probablement cette fonction dans mon premier indicateur où elle est utilisée assez souvent, alors que l'indicateur lui-même est beaucoup plus complexe et gourmand en ressources.
6. Dans OnDeinit() j'utilise :
où juste là est supprimé par le préfixe " l " (les noms " label" et " line" ont été utilisés lors de la création des objets.
7. Vous avez maintenant fait ce qu'un utilisateur qui a téléchargé et compris le code devrait faire. Vous avez trouvé les failles - cela fait aussi partie de l'apprentissage de MQL.
8. Bottom line : 1.) mon argument principal du code non-idéal de cet indicateur - simplicité, compacité et vitesse... 2.) mon deuxième argument principal du code imparfait - l'absence d'analogues en termes de vitesse et de polyvalence (voir la discussion sur l'original de quelqu'un d'autre) et la disponibilité d'améliorations par rapport à l'original, qui, soit dit en passant, est étroit et n'est pas plié en boucles compactes en termes de grand nombre de blocs répétés de manière similaire.
9. Malgré le point 7, vous n'avez pas vraiment compris le code de quelqu'un d'autre. Votre score de 2 est trop faible. Je ne vous recommande pas encore d'évaluer les logiciels par leur code. Je ne parlerai pas d'objectivité car il est impossible d'en attendre d'un seul utilisateur. Une estimation objective (cote) n'est possible qu'en tant que somme des estimations de quelques utilisateurs sains d'esprit et elle ne doit pas nécessairement être élevée.
La suppression par préfixe est la suivante : ObjectsDeleteAll(0, "pref_") ; // "pref_label" et " pref_line".
Ajouter au moins la première ligne à OnCalculate pour qu'il soit adressé à une nouvelle barre et non à chaque tick comme c'est le cas actuellement.
Supprimez par préfixe, c'est comme ça : ObjectsDeleteAll(0, "pref_") ; // "pref_label" et " pref_line".
Ajouter au moins si la première ligne à OnCalculate, de sorte que la référence est sur une nouvelle barre, et non sur chaque tick, comme il est maintenant
A propos, concernant le point 7 : j'ai rencontré des erreurs même dans la documentation de MQL5, qui ne sont pas corrigées pendant de nombreuses années.
La suppression par préfixe est la suivante : ObjectsDeleteAll(0, "pref_") ; // "pref_label" et " pref_line".
Le supprimer comme vous le suggérez n'est pas raisonnable car le début du préfixe est dynamique : soit{D1}, soit {W1}, soit{MN1} et ensuite vient le préfixe immuable comme " l... ". Vous pouvez interchanger les préfixes dynamiques et statiques et les supprimer en toute sécurité en fonction de votre version. Mais ce n'est pas raisonnable car il est peu pratique de prendre une information comme "R1{D1}", alors qu'il est plus pratique d' utiliser "{D1} R1". J'ai réfléchi à tout cela il y a longtemps et j'ai fait exactement ce que j'ai fait.
Il n'y a pas de moyen raisonnable de le supprimer comme vous le suggérez, car le début du préfixe est dynamique : soit{D1} , soit {W1} , soit{MN1}, et il y a ensuite un préfixe immuable comme " l...". Vous pouvez interchanger les préfixes dynamiques et statiques et les supprimer en toute sécurité en fonction de votre version. Mais ce n'est pas raisonnable car il est peu pratique de prendre une information comme "R1{D1}", alors qu'il est plus pratique d' utiliser "{D1} R1". J'ai réfléchi à tout cela il y a longtemps et j'ai fait exactement ce que j'ai fait.
DrawTheLine("pref"+line_types[lt], StPourtant, oui, en principe, vous pourriez le faire. Je me suis expliqué plus haut de manière fringante, en pensant à l'époque à :
pas sur les noms d'objets. Le graphique lit exactement ce qui est défini avecOBJPROP_TEXTpour les étiquettes, mais les noms d'objets peuvent être signés d'une manière moins lisible, car ils sont cachés et rarement lus.
En revanche, dans la "Liste des objets". (Ctrl+b) il est préférable de voir des noms d'objets lisibles, donc ma méthode est plus préférable. En plus de cela, il y a des cas où les noms d'objets doivent être extrêmement longs, donc un"pref_" supplémentaire sera totalement inacceptable.Pourtant, oui, en principe, vous pourriez le faire. Je m'expliquais plus haut de manière fringante, en pensant à ce moment-là :
pas sur les noms d'objets. Le graphique lit exactement ce qui est défini avecOBJPROP_TEXTpour les étiquettes, mais les noms d'objets peuvent être signés moins lisibles, car ils sont cachés et rarement lus.
En revanche, dans la "Liste des objets". (Ctrl+b) il est souhaitable de voir des noms d'objets lisibles, donc ma version est toujours préférable. En outre, il existe des cas où les noms d'objets doivent être extrêmement longs, de sorte qu' un"pref_" supplémentaire serait totalement inacceptable.et si quelqu'un aura encore un programme avec des objets graphiques, votre genre de préfixe "l" < où il suffit de supprimer par préfixe " l " (les noms "label" et "line" étaient utilisés lors de la création des objets >.
Tue tous les objets commençant par"l" dans un programme tiers. Ce n'est pas une bonne solution
et si quelqu'un d'autre a un programme avec des objets graphiques, votre type préfixe "l" < où est la suppression par préfixe "l" (les noms "label" et "line" ont été utilisés lors de la création des objets >.
Tue tous les objets commençant par"l" dans un programme tiers. Ce n'est pas une bonne solution.
Vitaly, pourquoi n'allez-vous pas dans le fil des débutants ? Ces bases, le programmeur les connaît plus ou moins depuis longtemps. Et seuls les "stars" ne le savent pas tous...