Fonction OrderSendAsync() - page 6
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
sergeev:
Sps ! Il s'avère qu'une demande asynchrone envoyée avec succès peut facilement se perdre et ne pas figurer dans l'historique.
Non.
Expliquez, s'il vous plaît. "Non", ma conclusion est-elle incorrecte, ou est-ce une confirmation de celle-ci ?
Il s'agit très probablement d'une conclusion erronée, mais Renat a dit précédemment que "si la requête n'a pas atteint le serveur, elle n'a aucune chance d'apparaître dans le terminal du client". Si nous continuons avec cette logique : si la requête n'a aucune chance d'apparaître dans le terminal client, elle n'a aucune chance d'entrer dans le terminal de base et donc aucune chance d'entrer dans la base des ordres historiques. Si ce raisonnement n'est pas correct, où se trouve l'erreur et quelle est-elle ?
Le fait est que la demande asynchrone ne donne pratiquement aucun statut "envoyé avec succès".
La réussite de la fonction signifie seulement que "du point de vue du client, l'ordre semble correct et a été jeté dans le tuyau du réseau, attendez la réponse dans OnTrade".
J'espère que dans un futur proche, OnTrade sera amélioré de telle sorte que le contrôle"request did not reach the server" puisse être organisé par l'utilisateur sans aucun problème et, en fait, aussi bien que d'autres types de contrôle d'exécution.
car dans sa forme actuelle, OnTrade n'est pas capable de telles prouesses, car il n'a aucune idée du type de réponse sur lequel il travaille.
J'espère que OnTrade sera finalisé dans un futur proche afin que le contrôle"request has not reached the server" puisse être organisé par l'utilisateur sans problème, ainsi que d'autres types de contrôle d'exécution.
car dans sa forme actuelle, OnTrade est incapable de telles prouesses, car il n'a aucune idée du type de réponse sur lequel il travaille.
En principe, nous pouvons ajouter une réponse virtuelle "request failed by timeout" si, après l'envoi de la demande, nous n'avons pas reçu de réponse du serveur dans les 5 à 10 secondes que la demande a atteint le serveur.
Cela nous permettra d'attraper une demande rebondie dans OnTrade. Mais pour ce faire, nous devrons surcharger la fonction en y ajoutant des paramètres.
Si la demande n'a pas atteint le serveur, aucun événement commercial ne sera généré qui pourrait se rapporter à cette demande "manquante". N'est-ce pas ?
Oui, c'est logique.
Nous pouvons ajouter une réponse virtuelle comme je l'ai décrit ci-dessus. Cela nous permettra de contrôler l'exécution des opérations asynchrones.
En principe, nous pouvons ajouter une réponse virtuelle "request failed by timeout" si, après avoir envoyé la demande, nous ne recevons pas de réponse du serveur dans les 5 à 10 secondes que la demande a atteint le serveur.
Cela vous permettra d'attraper le rebond d'un ordre dans OnTrade. Mais pour ce faire, vous devrez surcharger la fonction en y ajoutant des paramètres.
Tu me fais peur,
Les gens attendent l'amélioration de OnTrade avec des paramètres pour mettre en œuvre le contrôle de l'exécution. Vous avez sonné qui sera "dans une construction" c'est-à-dire chronologiquement dans la suivante.
J'ai eu trois commandes qui traînaient depuis des mois, attendant un délai d'attente, et vous dites "nous pouvons... "mais nous devons surcharger..."
Vous ne faites pas un raffinement de OnTrade ?
Je ne sais pas pour les autres, mais je ne suis pas satisfait de la situation actuelle. Je repousse l'écriture de tous les codes jusqu'à ce que MQL5 ait une fonction qui garantisse un contrôle direct de l'exécution, et non indirect.
Tu me fais peur,
Les gens attendent des améliorations à OnTrade avec des paramètres pour mettre en œuvre la surveillance de l'exécution. Vous avez dit que ce sera "dans un seul build", c'est-à-dire chronologiquement dans le prochain build.
J'ai trois commandes en attente depuis des mois, et vous dites "on peut... "mais nous devons surcharger..."
N'êtes-vous pas en train de faire un perfectionnement de OnTrade ???
Nous allons essayer de le faire dans la prochaine version.
Il y a en fait beaucoup de tâches en cours, et en plus c'est la période des vacances d'été - il est difficile de maintenir le rythme habituel de développement.
Mettons-nous au travail et essayons de le faire dans la prochaine version.
Les tâches à accomplir dans le cadre de ce travail sont vraiment nombreuses, et il est encore temps de prendre des vacances - en été, le rythme habituel de développement est difficile à maintenir.
Ouf, c'est un soulagement :)
vraiment effrayé, parce que c'est une situation réelle, on s'est parlé et on a oublié, et les gens attendent avec espoir :)
J'aimerais pouvoir vivre assez longtemps :))
Les méthaquotes constituent un terminal solide, léger et polyvalent .
Solides et légers, ils ont déjà appris à les fabriquer. Mais il y a une autre tâche à accomplir : la continuité. Nous devons relier en un seul terminal tous les "points d'étranglement" des différentes plates-formes de négociation et d'un grand nombre de courtiers. Je pense que c'est le problème. Il n'y a plus de MQ5 universel.
PS Oui Les paramètres OnTrade sont en attente. Et sur nos courtiers en bourse. Et nous avons besoin d'un moyen efficace de gérer l'asynchronie. Ensuite, il ne semble pas y avoir de concurrents (pour les terminaux). Le testeur seul vaut beaucoup...
En principe, nous pouvons ajouter une réponse virtuelle "request failed by timeout" si, après avoir envoyé la demande, nous ne recevons pas de réponse du serveur dans les 5 à 10 secondes que la demande a atteint le serveur.
Cela nous permettra d'attraper une rupture de demande dans OnTrade. Mais pour cela, nous devrons surcharger la fonction avec des paramètres ajoutés.
Nous pouvons ajouter une réponse virtuelle comme je l'ai décrit ci-dessus. Cela nous permettra de contrôler l'exécution des opérations asynchrones.
Asynchronie sans contrôle = chaos.
Le contrôle de l'asynchronisme ne peut être effectué que dans OnTrade().
Il est nécessaire d'identifier une demande particulière dans OnTrade().
Nous en arrivons donc à ce que OrderSendAsync() doit retourner le numéro du ticket reçu du serveur (en excluant la situation de time-out). Le numéro de ticket est nécessaire pour identifier de manière unique la demande, tant du côté du serveur que du côté du client.
En unifiant ce mécanisme, la fonction OrderSend() peut également être repensée - elle devrait renvoyer le numéro du ticket, ou "-1" en cas d'échec de l'envoi de la commande au serveur.
Ensuite, dans le programme, implémentez une classe avec la liste des tickets générés.
A chaque événement OnTrade(), nous comprenons :
1. s'il s'agit de notre action, ou, par exemple, de l'action d'une autre instance de l'Expert Advisor (les mages ne seront plus nécessaires).
2. Le type de demande à laquelle nous recevons une réponse.