Erreurs, bugs, questions - page 895
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
Comment connaître le bénéfice d'une position en passant par un trade magique ? Le commerce de fermeture ne va pas là parce qu'il n'a pas de magik.
IDENTIFICATEUR DE POSITION
L'ID du poste est un numéro unique attribué à chaque poste nouvellement ouvert et ne change pas tout au long de sa vie. Un retournement de la position ne modifie pas l'identifiant de la position.
long
DEAL_POSITION_ID
Identifiant de la position, en ouverture, modification ou fermeture de laquelle cette affaire a été impliquée. Chaque position possède un identifiant unique, qui est attribué à toutes les transactions effectuées sur l'instrument pendant la durée de vie de la position.
long
Une terminaison anormale signifie que l'Expert Advisor est en boucle, qu'il ne vérifie pas IsStopped et qu'il est forcé de s'arrêter par le terminal.
Je peux noter que la terminaison anormale n'est pas seulement due au code MQL, mais aussi à des hoquets internes du runtime lui-même. Disons que la terminaison anormale incontrôlable du MQL.
Par exemple, lorsque le code MQL envoie une commande de suppression d'objetSupprimer un objet d'un graphique qui existe déjà (ni objet ni graphique). Mais il était là au moment où la commande a été envoyée.
Et le code MQL n'attendra pas la réponse de la commande, puisque le blocage ne s'est pas produit dans le code MQL, mais dans les profondeurs de l'exécution. C'est-à-dire, dans ObjectDelete lui-même. En conséquence, nous obtiendrons une fin anormale.
Le deuxième cas le plus fréquent est l'utilisation de la fonction ObjectsDeleteAll. Puisqu'elle est synchrone, elle s'accroche également à la suppression des objets qui ont déjà été supprimés, mais seulement après son appel.
Le troisième cas est le plus dangereux, lorsque le runtime ne peut pas terminer la commande Expert Advisor de Deinit, parce que l'EA a été supprimé du graphique et que celui-ci est fermé. Nous aurons également un gel de l'environnement et une cessation anormale incontrôlée.
Tout ce que j'ai décrit ci-dessus concerne spécifiquement la fin du travail de l'expandeur dans la fonction OnDeinit. Quelque part dans les profondeurs du code, il y a une incohérence entre les actions de fin, d'abord avec la présence de la carte, et ensuite - avec le comportement de l'environnement à Deinit de l'expert.
Quelqu'un fait quelque chose plus tôt et provoque une terminaison anormale.
Bien sûr, dans certains cas, j'ai pu résoudre ce problème en vérifiant en plus la disponibilité. Mais il est rare qu'un seul des problèmes de synchronisation décrits se produise. La suppression/installation d'un indicateur sur un graphique qui tente de se fermer, la suppression d'objets.
J'aimerais avoir des réponses sur la façon dont il peut y avoir un prélèvement absolu SUPÉRIEUR au solde initial.
Bien que par définition.
Absolute Drawdown
Просадка от начального баланса показывает, насколько уменьшался баланс относительно первоначального значения. Максимально может быть равно начальному балансу, если потеряны все деньги.
Détaillé dans le sujethttps://www.mql5.com/ru/forum/8996
Une terminaison anormale signifie que l'EA est bouclée et ne vérifie pas IsStopped et est arrêtée de force par le terminal.
Faux.
Je pourrais noter que la terminaison anormale n'est pas seulement due au code MQL, mais aussi à des hoquets internes dans le runtime lui-même.
Oui, et il y a beaucoup de surprises de ce genre.
J'ai connu un blocage du terminal et l'impossibilité de supprimer le conseiller expert en raison d'une mémoire insuffisante. Dans ce cas, même la journalisation n'est pas toujours enregistrée.
Faux.
Oui, et il y a beaucoup de surprises comme ça.
J'ai rencontré des blocages de terminal et l'impossibilité de supprimer l'EA s'il n'y a pas assez de mémoire. Dans ce cas, même la journalisation ne fonctionne pas toujours.
IDENTIFICATEUR DE POSITION
L'identifiant du poste est un numéro unique qui est attribué à chaque poste nouvellement ouvert et qui ne change pas tout au long de sa durée de vie. L'inversion d'une position ne modifie pas l'identifiant de la position.
long
DEAL_POSITION_ID
Identifiant de la position, en ouverture, modification ou fermeture de laquelle cette affaire a été impliquée. Chaque position possède un identifiant unique, qui est attribué à toutes les transactions effectuées sur l'instrument pendant la durée de vie de la position.
long
Si j'ai bien compris, le sujet dehttps://www.mql5.com/ru/forum/8278 est lié à cette même question.
Non, c'était à propos des indicateurs.
Un conseiller expert qui dépasse une certaine limite de mémoire raccroche silencieusement le terminal. Cela se produit, par exemple, lorsque de nombreux graphiques de différents symboles/périodes avec des indicateurs sont chargés.
Je peux noter que la terminaison anormale n'est pas seulement due au code MQL, mais aussi à des hoquets internes du runtime lui-même. Disons donc que la terminaison anormale est incontrôlable à partir du MQL.
Par exemple, lorsque le code MQL envoie une commande pour supprimer un objet ObjectDelete d'un graphique qui existe déjà (ni un objet, ni un graphique). Mais il était là au moment où la commande a été envoyée.
Et le code MQL n'attendra pas la réponse de la commande, puisque le blocage ne s'est pas produit dans le code MQL, mais dans les profondeurs de l'exécution. C'est-à-dire, dans ObjectDelete lui-même. En conséquence, nous obtiendrons une fin anormale.
Le deuxième cas courant est l'utilisation de la fonction ObjectsDeleteAll. Puisqu'elle est synchrone, elle s'accroche également à la suppression des objets qui ont déjà été supprimés, mais seulement après son appel.
Le troisième cas est le plus dangereux, lorsque le runtime ne peut pas terminer la commande Expert Advisor de Deinit, parce que l'EA a été supprimé du graphique et que celui-ci est fermé. Nous aurons également un gel de l'environnement et une cessation anormale incontrôlée.
Tout ce que j'ai décrit ci-dessus concerne spécifiquement la fin du travail de l'expandeur dans la fonction OnDeinit. Quelque part dans les profondeurs du code, il y a une incohérence entre les actions de fin, d'abord avec la présence de la carte, et ensuite - avec le comportement de l'environnement à Deinit de l'expert.
Quelqu'un fait quelque chose plus tôt et provoque une terminaison anormale.
Bien sûr, dans certains cas, j'ai pu résoudre ce problème en vérifiant en plus la disponibilité. Mais il est rare qu'un seul des problèmes de synchronisation décrits se produise. La suppression/installation d'un indicateur sur un graphique qui tente de se fermer, la suppression d'objets.
Non, c'était à propos des indicateurs.
Un conseiller expert qui dépasse une certaine limite de mémoire raccroche silencieusement le terminal. Cela se produit, par exemple, lorsque de nombreux graphiques de différents symboles/périodes avec des indicateurs sont chargés.