Fonction OrderSendAsync() - page 3

[Yedelkin]

Message technique. Rassembler les déclarations intéressantes en un seul sujet.

sergeev:

Yedelkin:
Quelle propriété du compte sera responsable de la limite d'ordres simultanés dans la file d'attente d'exécution ? Sera-t-il possible de trouver ce chiffre de manière programmatique ?

le résultat de la fonction OrderSendAsync = false sera simplement

utilisez-le comme un guide

[Mykola Demko]

Rosh:

J'ai relu le fil de discussion avec intérêt, et je l'ai même testé en pratique, et j'ai découvert ici la discrimination flagrante du trading automatique.

Voici le journal de la fermeture des postes manuels : (chronologie compréhensible de bas en haut)

2012.04.26 22:32:05     Trades  '686934': deal #9256820 sell 0.02 EURUSD at 1.32391 done (based on order #10091825)
2012.04.26 22:32:05     Trades  '686934': order #10091825 sell 0.02 / 0.02 EURUSD at 1.32391 done
2012.04.26 22:32:05     Trades  '686934': accepted instant sell 0.02 EURUSD at 1.32391
2012.04.26 22:32:04     Trades  '686934': instant sell 0.02 EURUSD at 1.32391

Ce que nous voyons ici : l'ordre est envoyé, l'ordre est accepté, un ticket est attribué à l'ordre, et enfin l'ordre est exécuté (il peut y avoir quelques décalages dans l'interprétation, mais c'est à peu près tout). Tout est classique.

La seule chose étrange est que l'événement Trades sait avec certitude (dans le terminal) par quelle catégorie il a été déclenché, ainsi que par quel ordre (pour les deux dernières catégories) ; sinon il serait impossible d'émettre un tel commentaire, et le programmeur devrait réinventer la roue pour obtenir cette information. Et la situation avec la fonction OrderSendAsync n'a rien simplifié du tout.

Cependant, il faut noter que la vitesse d'exécution des ordres a augmenté. Maintenant, nous n'avons pas le temps de remarquer que l'ordre est placé dans la file d'attente, et il a déjà été exécuté.

---

Nous avons donc un paquet d'ordres, dont chacun vient théoriquement 4 Trades, dans chacune des Trades nous aurions besoin de contrôler chaque ordre.

Ainsi, nous avons 4*Number_Order*Number_Order points de contrôle, c'est-à-dire que nous avons 400 pour 10 commandes et 40000 pour 100. Et si jamais un ordre avait un nombre de transactions inférieur à 4, toute la logique de contrôle s'effondrerait, puisque l'attente avant l'envoi d'un deuxième ordre (si la première demande n'est pas exécutée) a lieu exactement au numéro 4.

[Andrey Dik]

Vous avez envoyé une pile d'ordres commerciaux au serveur.

Pour chaque ordre, devez-vous tenir un contrôle d'exécution distinct ? Et combien de temps attendons-nous pour une réponse ?

[---]

joo:

Chaque commande doit-elle être suivie séparément ?

Oui

Et combien de temps dois-je attendre pour obtenir une réponse ?

Cela varie d'un courtier à l'autre. S'il s'agit d'un STP, la question se pose plutôt pour son fournisseur de liquidités.

[Mykola Demko]

sergeev:

Oui,

Ils n'ont pas la même fonction pour les différents courtiers. S'il s'agit d'un STP, la question se pose davantage pour leur fournisseur de liquidités.

Non, tout est deviné par le marc de café. Lorsque vous ouvrez la fenêtre manuellement, vous appuyez sur acheter, attendez une requote ou une exécution, appuyez sur ok et vous avez terminé.

Lorsque vous ouvrez en mode automatique, il devrait également y avoir un point de référence, à partir duquel vous devez envoyer une deuxième demande, sinon tout est OK.

SZS a ajouté au message ci-dessus, relisez.

[---]

Urain:

Non, ce n'est qu'une supposition, lorsque vous ouvrez manuellement une fenêtre, appuyez sur acheter, attendez une requote ou une exécution, appuyez sur ok et vous avez terminé.

Non. C'est le cas lorsque le code de retour est DONE(10009).

Mais il existe des courtiers qui transmettent votre transaction au fournisseur. Et dans ce cas, ils vous renverront immédiatement PLACED(10008). Et d'ailleurs, s'il s'agissait d'un ordre au marché, il n'y aura pas de ticket Deal dans cette réponse, seulement le ticket d'ordre.

Et il n'y aura même pas de ticket pour la commande dans le cas de OrderSendAsync.

En mode automatique, il doit s'agir du point de référence à partir duquel vous souhaitez envoyer une deuxième demande, sinon tout est OK.

Quel est le point de référence des requêtes, même sur MT4 ? Vous ne ferez pas une boucle sans fin en attendant la suppression ou l'ouverture d'un ordre.

Tout se passe comme prévu, avec des vérifications des états sauvegardés, etc.

[Yedelkin]

J'ai essayé d'exécuter la fonction OrderSendAsync()

//+------------------------------------------------------------------+
//|                                               OrderSendAsync.mq5 |
//+------------------------------------------------------------------+
MqlTradeResult  res={0};
MqlTradeRequest req={0};
//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
   req.action=TRADE_ACTION_PENDING;
   req.symbol=_Symbol;
   req.volume=1.0;
   req.price=3.0;
   req.type=ORDER_TYPE_BUY_STOP;
   req.type_filling=ORDER_FILLING_RETURN;
   switch(OrderSendAsync(req,res))
     {
      case  true:
         Print("retcode=",res.retcode,", order=",res.order,", deal=",res.deal);
         break;
      default: Print("Неудача при отправке запроса функцией OrderSendAsync()");
     }
  }

Elle a répondu par

2012.05.02 21:12:33 OrderSendAsync (USDCHF,M1) retcode=10008, order=0, deal=0

Une question rapide se pose : comment envisageons-nous de retracer le sort d'une demande de transaction lorsqu'elle est envoyée à l'aide de la fonction OrderSendAsync(), si nous ne connaissons même pas le ticket d'ordre ? Le commentaire doit être rempli par le courtier.

[Renat Fatkhullin]

Le mode asynchrone est conçu pour la saisie de commandes par lots en masse, mais pas pour une transaction unique. Pour une transaction unique, il est préférable d'utiliser le mode synchrone - tout s'exécutera à la même vitesse, et avec un service complet.

Suivre l'exécution des transactions asynchrones dans OnTrade. Oui, c'est un chemin plus compliqué, mais c'est le prix de l'asynchronie.

[Yedelkin]

Renat:
Le mode asynchrone est conçu pour la saisie de commandes par lots en vrac, mais pas pour une seule transaction. Pour une transaction unique, il est préférable d'utiliser le mode synchrone - tout sera exécuté à la même vitesse et avec un service complet.

Suivre l'exécution des transactions asynchrones dans OnTrade. Oui, c'est une méthode plus compliquée, mais c'est le prix de l'asynchronie.

Ok, laissez-moi clarifier une question : comment quelqu'un va-t-il suivre le sort de cinq cents demandes de transaction dans un envoi massif d'ordres par lots ? Étant donné que tout envoi massif de commandes par lots est constitué d'un grand nombre de transactions individuelles, chacun utilisera-t-il le principe de la comparaison entre l'état antérieur et l'état actuel de l'histoire ? N'y a-t-il pas d'autres approches ?

[Renat Fatkhullin]

La base de la compréhension est que les processus asynchrones
1) ne garantit pas la rapidité ou même la disponibilité de la réponse
2) exige clairement des files d'opérations distinctes de la part du développeur

En d'autres termes, nous devrons générer une liste d'ordres, puis les vérifier et les exécuter dans OnTrade. Ceci, bien sûr, est atroce.

Pour notre part, nous pourrions maintenir de manière transparente des files d'attente asynchrones, les remplir de réponses et fournir aux commerçants des fonctions pratiques pour vérifier et récupérer les entrées traitées dans la file d'attente. Vous pouvez vérifier les files d'attente de manière asynchrone dans OnTrade ou de manière synchrone en interrogeant dans la boucle juste après l'envoi d'un lot d'ordres.

Nous allons réfléchir à un tel mécanisme - il faciliterait la vie des développeurs d'EE en les soulageant de leur routine.