Fonction OrderSendAsync()

Yedelkin  

La description indique quela fonction OrderSendAsync() est conçue pour effectuer des opérations asynchrones sans attendre que le serveur réponde à la demande envoyée. En cas d'exécution réussie, le code de réponse dans la variable de résultat contient la valeur TRADE_RETCODE_PLACED ( code 10008) - "commande passée". L'exécution réussie de . ne nous donne aucune garantie que la demande a atteint le serveur commercial et a été acceptée pour traitement.

D'une part, nous savons que le champ retcode contient le code de retour du serveur commercial - c'est-à-dire que l'on suppose que ce code est généré par le serveur, et non par le terminal de l'utilisateur. D'autre part, le manuel de référence indique que pour lafonction OrderSendAsync(), l'un des codes à générer par le serveur (code 10008) peut être renvoyé même si la demande de transaction elle-même n'a pas atteint le serveur de transaction.

Question 1 : Où exactement (à quelle étape) le code 10008 est-il généré pour lafonction OrderSendAsync ? [En supposant que ce code puisse être renvoyé sans que le serveur commercial soit impliqué].

Question 2 : Le code 10008 est-il le code du serveur de transaction ou ce code est-il généré du côté du terminal client avant que la demande de transaction ne soit reçue par le serveur ?

Документация по MQL5: Стандартные константы, перечисления и структуры / Структуры данных / Структура торгового запроса
Документация по MQL5: Стандартные константы, перечисления и структуры / Структуры данных / Структура торгового запроса
  • www.mql5.com
Стандартные константы, перечисления и структуры / Структуры данных / Структура торгового запроса - Документация по MQL5
Rashid Umarov  

1. terminal, en cas de réussite de l'opération de répartition (la commande a été déposée avec succès de l'avion, mais nous ne savons pas ce qui va suivre)

Je m'excuse pour cette tautologie, mais je répondrai de la même manière : Oui, le code 10008 est le code de réponse du serveur commercial. Oui, ce code est défini par le terminal au moment de... point suivant 1.

Pourquoi essayez-vous de trouver entre les lignes ce qui est déjà écrit explicitement ?

hrenfx  

Le modèle d'ordre commercial asynchrone suppose de multiples événements et états d'ordre :

Diagramme des états des ordres du marché

Diagramme d'états d'ordres conditionnels

Actuellement dans MT5 :

  1. CREATED - le fait même de l'appel de la fonction OrderSendAsync et OrderSend (cet état d'ordre dans MT5 n'est en aucun cas identifiable de l'extérieur).
  2. Si l'ordre est ANNULÉ (le terminal lui-même l'a coupé à travers ses filtres. Par exemple, le prix limite est inférieur au prix actuel), la réponse est négative à partir de OrderSend et OrderSendAsync.
  3. OPENED est le résultat de TRADE_RETCODE_PLACED (votre ordre passe avec succès les filtres internes du terminal et est envoyé au serveur) pour OrderSendAsync.
  4. SUBMIT_OK - le serveur a accepté votre ordre de transaction. S'il s'agit d'un ordre en attente, OrderSend achèvera son exécution. Si c'est le cas, continuez à attendre.
  5. FILLE - votre ordre est en cours d'exécution (par exemple, vous l'avez envoyé via STP et vous attendez une réponse). Continuez à attendre.
  6. FILL_OK - votre ordre a été exécuté. S'il s'agit d'un marché, l'ordre d'envoi terminera son exécution.

Veuillez consulter les diagrammes ci-dessus pour plus de détails.

Yedelkin  
Rosh:

1. terminal, en cas de réussite de l'opération de répartition (la commande a été déposée avec succès de l'avion, mais nous ne savons pas ce qui va suivre)

Je m'excuse pour cette tautologie, mais je répondrai de la même manière : Oui, le code 10008 est le code de réponse du serveur commercial. Oui, ce code est défini par le terminal au moment de... point suivant 1.

Pourquoi essayez-vous de trouver entre les lignes de ce qui est déjà écrit explicitement ?

Je ne cherche pas à savoir ce qu'il y a entre les lignes, mais, encore une fois, j'essaie de comprendre les étapes de deux fonctions commerciales (maintenant).

Dans votre commentaire sur la fonction OrderSendAsync, vous dites que"la fonction est similaire à OrderSend() dans son but et ses paramètres". Mais, à en juger par votre réponse, la fonction OrderSendAsync n'est pas tout à fait la même que la fonction OrderSend. Cette dernière est destinée à vérifier la demande de transaction sur le serveur, de sorte que les codes renvoyés par OrderSend() sont les codes générés par le serveur lui-même, et non une autre substance. Dans le cas de OrderSendAsync() le code de retour est généré par le terminal, donc ce code (code 10008) ne peut pas être considéré comme un code de retour du serveur. Il s'agit de "code généré par le terminal", même si vous l'incluez formellement dans la liste de codes du serveur.

En d'autres termes, les deux fonctions correspondent à deux approches : "code généré par le serveur" et "code généré par le terminal". A cet égard, les fonctions ne sont pas les mêmes. Il faut connaître cette subtilité pour comprendre correctement si le "code retour" provient du serveur ou du terminal.

hrenfx  
Yedelkin:

Pouvons-nous conclure que TRADE_RETCODE_PLACED (10008) ne sert à rien du tout en termes d'attente lors de l'utilisation de la fonction originale OrderSend?

TRADE_RETCODE_PLACED n'a rien à voir avec l'envoi séquentiel d'ordres.

Comment traduire correctement "Order condition gets met" ?

Le prix actuel satisfait à la condition de l'ordre. Au lieu de REMPLIR, il peut être ANNULÉ, par exemple s'il n'y a pas assez de marge pour exécuter l'ordre.

Encore une fois, pour travailler de manière asynchrone, nous avons besoin d'un système d'événements puissant, où à l'arrivée il y a une option pour recevoir :

  • Le message texte de l'événement.
  • Le moment de sa création.
  • A quel ordre il se rapporte.
  • Le type de message (nouvelle, commande, état de la communication, etc.)

L'architecture de la plate-forme elle-même doit être très bien pensée. S'il existe des lacunes au stade de la conception de l'architecture, il est extrêmement difficile de les contourner pour atteindre l'universalité.

IMessage (JForex API 2.9.6.1 API)
  • www.dukascopy.com
FRAMES    NO FRAMES
Yedelkin  

hrenfx:

Yedelkin:

Pouvons-nous conclure que TRADE_RETCODE_PLACED (10008) ne sert à rien du tout en termes d'attente lors de l'utilisation de la fonction originale OrderSend?

TRADE_RETCODE_PLACED n'a rien à voir avec l'envoi séquentiel d'ordres.

Là-bas ! J'y suis arrivé intuitivement il y a environ six mois, et vous le confirmez en quelque sorte :) Déjà bon :)
Yedelkin  
hrenfx:

Là encore, pour travailler de manière asynchrone, il faut un système d'événements puissant où il existe une option de réception à l'arrivée :

  • Le message texte de l'événement.
  • Le moment de sa création.
  • L'ordre auquel il se réfère.
  • Type de message (nouvelles, commande, état de la communication, etc.)
S'agit-il, entre autres, de la nécessité de détailler l'événement OnTrade ?
Yedelkin  
Rosh:
Une personne est toujours heureuse lorsque quelqu'un confirme la justesse de son raisonnement. Peu importe à quel point c'est vrai.
Eh bien, au cours des huit derniers mois, personne n'a jamais réfuté la conclusion publique de cet homme. Ni en théorie, ni par des résultats de tests. Mais merci de semer le doute :)
hrenfx  

Il convient de le clarifier :

TRADE_RETCODE_PLACED pour OrderSend est la réponse du serveur.

TRADE_RETCODE_PLACED pour OrderSendAsync est une réponse terminale.

Bien que les codes soient identiques, ils ont une signification bien différente. Les développeurs vont très probablement corriger cette ambiguïté.

C'est pourquoi vous devez le comprendre :

TRADE_RETCODE_PLACED к последовательной OrderSend не имеет никакого отношения.

doit être comprise dans le contexte approprié.