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
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.
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 ?
Je ne me suis pas occupé de ce sujet, mais voici ce que dit le manuel :
Je ne me suis pas occupé de ce sujet, mais voici ce que dit le manuel :
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 ?
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
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.
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.
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 :)
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.