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
Vous ne comprenez rien. Lorsque nous retournons, nous entrons dans les fonctions On de la file d'attente générée. Cela peut provoquer une pause qui empêche le premier OrderSend d'envoyer le second correct.
Quelle est la durée de la pause/du retard ? Dans la copie de 3 structures ?
Vous proposez d 'accumuler la file d'attente en sauvegardant toutes les On-fonctions après le retour, en attendant la On-fonction qui dira que le premier OrderSend est terminé. Et ensuite seulement envoyer le deuxième OrderSend.
Il n'est pas nécessaire d'accumuler tous les événements. N'attendez pas le prochain événement pour copier - vous pouvez traiter les événements avant le retour et envoyer le deuxième OrderSend dès que les conditions préalables sont réunies pour cela.
Vous ne réalisez pas non plus que la position de prise peut être exécutée pendant le premier envoi d'ordre, mais que son OnTradeTransaction sera dans la file d'attente plus tard (dans la même microseconde, mais plus tard) que le OnTradeTransaction final du premier envoi d'ordre.
Et comment cela vous aide-t-il dans une telle situation ?
bool HandleNextEvent(ENUM_EVENT_TYPE);
Elle sera la dernière ici comme là-bas
Vous ne comprenez rien. Lorsque nous retournons, nous entrons dans les fonctions On de la file d'attente générée. Cela peut provoquer une pause qui empêche le premier OrderSend d'envoyer le second correct immédiatement après le premier.
Vous proposez d'accumuler la file d'attente en sauvegardant toutes les On-fonctions après le retour, en attendant la On-fonction, dans laquelle il y aura un message sur la fin du premier OrderSend. Et ensuite seulement envoyer le deuxième OrderSend.
En même temps, vous ne comprenez pas que la position de prise peut être exécutée pendant le premier envoi d'ordre, mais que son OnTradeTransaction sera dans la file d'attente plus tard (dans la même microseconde, mais plus tard) que le OnTradeTransaction de fin du premier envoi d'ordre.
Il n'y a pas de file d'attente. Le nouvel événement sera traité après l'événement actuel, et tous les événements qui se sont produits pendant cette période seront ignorés.
À mon avis, la solution au problème serait de pouvoir "s'abonner" à une commande. C'est-à-dire que le terminal doit générer un événement lorsqu'une transaction sur une commande se produit.
Mais cela devrait être mis en œuvre par les développeurs, pas par nous. Toutes nos solutions, d'une manière ou d'une autre, reviendront à l'histoire des transactions. Je n'ai pas une telle criticité à la microseconde, mais c'est vraiment...
Mais il est vraiment ennuyeux d'écrire des bikes complexes pour savoir si une transaction est passée ou non, si des niveaux sont déclenchés ou si quelqu'un a corrigé une position dans le terminal.
Bien que cela puisse sembler une chose simple - un événement sur une transaction sur une position - et tout serait beaucoup plus facile.
Mais c'est aux développeurs de mettre cela en œuvre, pas à nous.
Les développeurs doivent uniquement fournir les outils. MQL est essentiellement un langage de programmation de bas niveau (tout comme C++). Vous l'utilisez non pas en termes de tâches mais en termes de calculs. Et vous prenez toutes les décisions de haut niveau par vous-même. Vous manquez peut-être d'outils, mais pas de solutions toutes faites
Quel est le délai de pause ? En copiant 3 structures ?
En traitant une file d'attente d'événements divers.
Comment cela vous aiderait-il dans une telle situation ?
Ce sera le dernier ici ou là.
Je serai attentif à la fermeture de la prise.
Il n'y a pas de file d'attente. Le nouvel événement sera traité après l'événement actuel et tous les événements qui se sont produits pendant cette période seront ignorés.
Incompétent.
Il y a plusieurs événements dans la file d'attente à traiter.
Je serai attentif à la proximité du tee.
Arrêtons-nous au fait que je ne comprends vraiment pas les choses élémentaires (sans code avecHandleNextEvent).
Pour finir, la différence entre leHandleNextEvent proposé et ce que j'ai écrit est que c'est via une récursion et que je l'ai fait via une boucle. De plus, la file d'attente est initialement formée et vous pouvez la gérer ... vous traitez certains événements en une fois et les reportez à un autre moment, vous avez une liberté totale.
En même temps, le même contrôle, cousu dans le conseiller en négociation de combat sur le même Terminal, Alerte. Quelle pourrait être la raison ?
Forum sur le trading, les systèmes de trading automatisé et les tests de stratégies de trading
MT5 et la vitesse en action
Anton, 2020.05.29 16:21
Script pour le test du temps maximum et moyen :
2474.
Il est devenu très bon. Si vous l'avez modifié - Merci. Je garderai un œil sur les performances en mode combat.
PS En mode combat, lorsque des transactions sont effectuées, il y a presque toujours un décalage (uniquement pour les sorties supérieures à 5 millisecondes).
Sinon, il semble être bien meilleur que le 2470.