Questions OrderSend() - page 8

 

En attendant un article sur ce sujet, est-ce que je comprends bien le concept général de l'analyse des opérations commerciales.

...
bool AllowTrade = true;
ulong OrderTicket;
...
void OnTick() {
  ...
  if (!AllowTrade) return;
  ...
  MqlTradeResult Result;
  if (OrderSend(...)) {
    Ticket = Result.order;
    AllowTrade = false;
  }
}
...
void OnTrade() {
  if (AllowTrade) return;
  if (OrderSelect(Ticket)) {
    if (...)
    ...
    // AllowTrade = true|false;
  }
  else AllowTrade = true;
}
...

C'est-à-dire qu'en gros, après avoir envoyé un ordre sans analyser le retcode, nous interdisons les opérations de trading dans la boucle de travail (OnTick()) en utilisant l'indicateur "AllowTrade".

L'interdiction de transaction n'est débloquée dans OnTrade() qu'après avoir trouvé le numéro de l'ordre et analysé son sort.

Nous avons deux questions :

1. Quel est le ticket de commande à vérifier dans OnTrade ? Quels sont les statuts définitifs dans sa durée de vie ?

2. Je sais que la file d'attente des événements Tick (OnTick) peut "tomber". C'est-à-dire que si un autre événement Tick arrive et que la fonction OnTick (du Tick précédent) n'a pas encore terminé son travail, l'événement actuel sera "abandonné", c'est-à-dire qu'il ne sera pas traité. Existe-t-il une approche similaire pour les événements commerciaux (OnTrade) ? Autrement dit, est-il possible que, par exemple, dans la boucle principale, je mette une interdiction de transaction et que l'événement OnTrade de l'ordre qui vient d'être envoyé "tombe", parce qu'au moment de son arrivée, je serai encore en train de traiter quelque chose dans le même tick que l'envoi de l'ordre de transaction correspondant ?

 
voix_kas: En d'autres termes, y a-t-il une probabilité que, par exemple, je place une interdiction de transaction dans la boucle principale et que l'événement OnTrade de l'ordre qui vient d'être envoyé "tombe", car au moment de son arrivée, je serai encore en train de traiter quelque chose dans le même tick que l'envoi de l'ordre de transaction correspondant ?

Je ne me suis pas occupé de ce sujet, mais voici ce que dit le manuel :

1) La longueur de la file d'attente des transactions est de 1024 éléments. Si la fonction OnTradeTransaction() prend trop de temps pour traiter une autre transaction, les anciennes transactions de la file d'attente peuvent être remplacées par des transactions plus récentes ;

2) OnTrade est appelé après les appels OnTradeTransaction appropriés.

 
Yedelkin:

Je ne me suis pas occupé de ce sujet, mais voici ce que dit le manuel :

1) La longueur de la file d'attente des transactions est de 1024 éléments. Si la fonction OnTradeTransaction() prend trop de temps pour traiter une autre transaction, les anciennes transactions de la file d'attente peuvent être remplacées par des transactions plus récentes ;

2) OnTrade est appelé après les appels OnTradeTransaction appropriés.

Généralement compris. Commepapaklass l'a déjà souligné et dit dans l'article https://www.mql5.com/ru/articles/232:

Il n'y a qu'un seul moyen garanti de savoir exactement ce qui a changé sur un compte commercial. Cette méthode consiste à se souvenir de l'état de la transaction et de l'historique des transactions et à comparer le nouvel état avec celui qui a été sauvegardé.

Un autre bloc de services dans le conseiller expert. :(

En fait, la question est la suivante . Peut-on réduire la taille du code sans analyser toutes les variables (ordres/trades/positions), et se concentrer uniquement sur le numéro d'ordre obtenu à partir du résultat de l'OrderSend ? Ou ce nombre peut être non unique/non reflété dans l'historique ?

 
voix_kas: Peut-on réduire la taille du code sans analyser toutes les variables (ordres/trades/positions), et se concentrer uniquement sur l'ordre dont le numéro est obtenu à partir du résultat de l'OrderSend ? Ou ce nombre peut être non unique/non reflété dans l'historique ?

Bien sûr. Si une demande de transaction a donné lieu à la réception d'un ticket d'ordre, ce ticket est unique et permet de retracer l'ensemble du destin de l'ordre.

Vous pouvez voir ici comment le ticket d'ordre est utilisé dans l'historique : Référence MQL5 / Fonctions de trading / HistoryOrderGetInteger

 
Yedelkin:
Bien sûr. Si une demande de transaction a donné lieu à un ticket d'ordre, ce ticket est unique et peut être utilisé pour suivre le sort de l'ordre.
Juste pour info. Dans le cas où l'ordre n'a pas été accepté par le serveur pour exécution, par exemple, une requote, la variable MqlTradeResult.order se voit-elle attribuer une valeur par défaut (par exemple, "0") ?
 
voix_kas: Dans le cas où un ordre n'a pas été accepté par le serveur pour exécution, par exemple une requote, la variable MqlTradeResult Result.order se voit-elle attribuer une valeur par défaut (par exemple "0") ?
Une variable de type MqlTradeResult est généralement mise à zéro avant d'être utilisée. Ainsi, le champ Result.order contient une valeur nulle. Je n'ai jamais vu ce champ prendre une valeur différente après l'envoi infructueux d'une demande de transaction.
Документация по MQL5: Торговые функции / OrderSend
Документация по MQL5: Торговые функции / OrderSend
  • www.mql5.com
Торговые функции / OrderSend - Документация по MQL5
 
Yedelkin:
Une variable de type MqlTradeResult est généralement mise à zéro avant d'être utilisée. Le champ Result.order contient donc une valeur nulle. Je n'ai jamais vu ce champ prendre une valeur différente après l'échec de l'envoi d'une demande de transaction.
Si vous le voulez bien, j'aimerais approfondir la question de l'interprétation des codes de retour. 24 des 30 réponses déclarées (espérons que nous ne rencontrerons pas de réponses non déclarées) indiquent clairement un échec de la commande. Les 6 autres : 1. TRADE_RETCODE_PLACED Supposons que nous ne plaçons pas d'ordres en attente. Cette réponse est-elle possible dans le cadre de la négociation sur le marché (SYMBOL_TRADE_EXECUTION_MARKET) ? 2. TRADE_RETCODE_DONE Rien d'autre ne peut être vérifié. Tout s'est déroulé exactement comme décrit par le Conseiller Expert. 3. TRADE_RETCODE_DONE_PARTIAL Je suppose que cette réponse est similaire à TRADE_RETCODE_DONE étant donné le mode ORDER_FILLING_IOC, si l'on trade sans ordres en attente. 4. TRADE_RETCODE_ORDER_CHANGED Cela signifie-t-il un rejet sans ambiguïté de notre ordre commercial ? 5. TRADE_RETCODE_LOCKED Je pense que c'est le pire des cas. Que devons-nous faire dans ce cas ? Je suggère que le numéro de commande n'est pas encore disponible. Le flux commercial est occupé. Nous ne pouvons pas commercer et il n'est pas clair comment nous pouvons savoir que le flux commercial est débloqué. 6. TRADE_RETCODE_FROZEN Cela signifie-t-il un rejet sans ambiguïté de notre ordre commercial ? Veuillez commenter chaque élément.
 

voix_kas: Если не возражаете, хотелось бы углубиться в вопрос интерпритации кодов возврата. Из 30 задекларированных вариантов ответа (будем надеятся, что с недекларированными мы не столкнёмся) 24 - указывают на явный отказ в размещении ордера. Остальные 6:  

1. TRADE_RETCODE_PLACED Supposons qu'il n'y ait pas d'ordres en attente. Cette réponse est-elle possible pendant la négociation sur le marché (SYMBOL_TRADE_EXECUTION_MARKET) ?

TRADE_RETCODE_DONE Rien d'autre ne peut être vérifié. Tout s'est déroulé exactement comme le conseiller expert l'avait demandé.

3. TRADE_RETCODE_DONE_PARTIAL Je suppose que cette réponse est la même que TRADE_RETCODE_DONE étant donné le mode ORDER_FILLING_IOC.

4. TRADE_RETCODE_ORDER_CHANGED Cela signifie-t-il un rejet sans ambiguïté de notre ordre commercial ?

5. TRADE_RETCODE_LOCKED Je pense que c'est le pire des cas. Que devons-nous faire dans ce cas ? Je suggère que le numéro de commande n'est pas encore disponible. Le flux commercial est occupé. Nous ne pouvons pas commercer, et il n'est pas clair comment nous devrions savoir si le flux commercial est débloqué ou non.

6. TRADE_RETCODE_FROZEN Cela signifie-t-il un rejet sans ambiguïté de notre ordre commercial ?

Veuillez commenter chaque point.

Malheureusement, mes connaissances ne sont pas suffisantes pour un commentaire complet sur chaque point. Eh bien, si quelque chose se produit, mes collègues le corrigeront.

1. Le forum a mentionné une fois une situation où un compte de trading peut être ouvert avec un sous-courtier. Dans ce cas, le sous-courtier peut envoyer la demande de transaction pour traitement ultérieur (au courtier) et envoyer TRADE_RETCODE_PLACED au terminal client. On ignore si le courtier traitera finalement une telle demande de transaction.

2. Oui, je le pense aussi. La seule chose à retenir est que les informations relatives à cet ordre seront reçues dans la base de données du terminal de manière asynchrone.

Je pense que nous parlons de l'exécution partielle d'une demande de transaction dans les modes ORDER_FILLING_IOC et ORDER_FILLING_RETURN.

4. https://www.mql5.com/ru/forum/1111/page124#comment_18407

5. Je ne sais absolument rien de ce code. Techniquement, il s'avère que la demande n'a pas été traitée pour des raisons internes au courtier. Il n'est pas clair si elle sera traitée ultérieurement. Pour ma part, j'assimile ce code au rejet d'une demande d'échange.

6. https://www.mql5.com/ru/forum/1111/page123#comment_18372

... Et en général, essayez de faire une recherche par mot-clé dans le forum. Vous pouvez y trouver beaucoup plus d'informations :)

 
Yedelkin:

Malheureusement, je n'ai pas assez de connaissances pour commenter pleinement chacun de ces points. Eh bien, si quelque chose, les collègues vont le corriger.

1. Le forum a mentionné une fois une situation dans laquelle un compte de trading peut être ouvert avec un sous-courtier. Dans ce cas, le sous-courtier peut envoyer la demande de transaction pour traitement ultérieur (au courtier) et envoyer TRADE_RETCODE_PLACED au terminal client. On ignore si le courtier traitera finalement une telle demande de transaction.

2. Oui, je le pense aussi. La seule chose à retenir est que les informations relatives à cet ordre seront reçues dans la base de données du terminal de manière asynchrone.

Je pense que nous parlons de l'exécution partielle d'une demande de transaction dans les modes ORDER_FILLING_IOC et ORDER_FILLING_RETURN.

4. https://www.mql5.com/ru/forum/1111/page124#comment_18407

5. Je ne sais absolument rien de ce code. Techniquement, il s'avère que la demande n'a pas été traitée pour des raisons internes au courtier. Il n'est pas clair si elle sera traitée ultérieurement. Pour ma part, j'assimile ce code au rejet d'une demande commerciale.

6. https://www.mql5.com/ru/forum/1111/page123#comment_18372

... Et en général, essayez de faire une recherche par mot-clé sur le forum. Vous pouvez y trouver beaucoup plus d'informations :).

Voici ce que nous constatons : 26 des 30 codes (dont TRADE_RETCODE_ORDER_CHANGED et TRADE_RETCODE_FROZEN) représentent un rejet explicite de la demande (ne génère pas d'ordre).

TRADE_RETCODE_DONE et TRADE_RETCODE_DONE_PARTIAL - ordre créé garanti.

Comment exécuter correctement TRADE_RETCODE_PLACED (non en attente) et TRADE_RETCODE_LOCKED est une question. Les commentaires de MQ sur ces deux codes seraient appréciés.

 
C'est cool, bonne année #2015 à tous, mais je me demande comment ça s'est terminé. C'est deux ans de silence....