Traitement des transactions (OnTradeTransaction) - page 2

Nouveau commentaire
 
fxsaber:

Peut-on avoir >=2 ordres take et stop en même temps ?

Oui, c'est vrai, nous avons effectué une entrée initiale et fixé un ordre TP et un ordre stop. Puis, quelque temps plus tard, nous pouvons avoir ajouté d'autres entrées et fixé d'autres TP et stops.

 

En cas de perte, je me souviens des commandes passées, du ticket de la dernière transaction comptabilisée, de l'heure du dernier enregistrement (changement) de l'état, et périodiquement, ainsi que pendant l'initing, je synchronise la liste des commandes et vérifie les transactions non comptabilisées.

L'occurrence d'événements aléatoires est la norme, l'absence d'ordres (temporaires) dans les ordres et dans l'historique n'est pas rare et peut se produire à la fois avant et après qu'une transaction ait eu lieu.

Une position au moment de la compensation reçoit un ticket du premier ordre et, lors de transactions (changements) ultérieures, l'enregistre jusqu'à ce qu'elle soit fermée (c'est-à-dire qu'elle devienne 0,0).

Eh bien, selon le volume de l'ordre, il peut générer plusieurs transactions.
 
Илья Ребенок:


Partagez vos expériences et vos idées, s'il vous plaît.

Vous ne faites pas les choses correctement dès le départ.

Pourquoi des magiciens et toutes sortes de contrôles ?

Le ticket d'une commande est un identifiant unique.

Si vous envoyez une commande synchrone, vous recevrez un ticket comme résultat de la fonction.

Si vous envoyez un ordre asynchrone, nous recevons le ticket dans OnTradeTransaction.

Ajouté

Et icihttps://www.mql5.com/ru/forum/67298/page2#comment_2089220

est une bonne fonction pour vérifier l'ordre

ФОРТС: В помощь начинающим
ФОРТС: В помощь начинающим
  • 2015.11.25
  • www.mql5.com
Установка отложенного ордера командой OrderSend().
 
Илья Ребенок:

Oui, c'est vrai, nous avons effectué une entrée initiale et fixé un ordre TP et un ordre stop. Ensuite, après un certain temps, nous pourrions faire un complément et placer un autre TP et des ordres stop.

Les ordres limités qui nécessitent un TP/SL peuvent être exécutés partiellement. En même temps, les TP sous forme d'ordres Limit seront exécutés de la même manière. Par exemple, le TP est exécuté par un tiers du volume - le SL doit être diminué de la même quantité.

En somme, une logique assez désagréable pour attraper tous les trucs.


La tâche doit être mise en œuvre dans OnTrade. Elle ne devrait pas être difficile à mettre en œuvre.

 
prostotrader:

Vous faites tout de travers depuis le début.

Pourquoi des magiciens et toutes sortes de contrôles ?

Le ticket d'une commande est un identifiant unique.

Si vous envoyez un ordre synchrone, alors le ticket est reçu comme résultat de la fonction.

Si vous envoyez un ordre asynchrone, nous recevons le ticket dans OnTradeTransaction.

Ajouté

Et icihttps://www.mql5.com/ru/forum/67298/page2#comment_2089220

est une bonne fonction pour vérifier l'ordre

Merci, je vais le lire.
JRandomTrader:

En cas de perte d'un événement, je me souviens des commandes passées, du ticket de la dernière transaction comptabilisée, de l'heure de la dernière entrée (changement) d'état, et périodiquement, ainsi que lorsque cela se produit, je synchronise la liste des commandes et vérifie les transactions non enregistrées.

L'occurrence d'événements aléatoires est la norme, l'absence d'ordre (temporaire) dans les ordres et dans l'histoire n'est pas rare et peut se produire à la fois avant et après qu'une transaction ait eu lieu.

La position à la compensation obtient un ticket du premier ordre et sur les transactions (changements) ultérieures, elle l'enregistre jusqu'à ce qu'elle se ferme (c'est-à-dire qu'elle devient 0,0).

Eh bien, selon le volume de l'ordre, il peut engendrer plusieurs transactions.

L'un des objectifs du robot était de se débarrasser de la dépendance locale. En d'autres termes, il ne reçoit que les données du marché sans être lié aux variables du terminal ou d'un PC. Cela signifie qu'en cas de besoin urgent, je n'ai qu'à passer à un autre PC et le robot récupère tout.

Maintenant, j'ai vu un autre bug intéressant. J'ai reçu 2 transactions TRADE_TRANSACTION_DEAL_ADD identiques. Je suis désolé, qu'est-ce que c'est que ça ?) Le robot a fini par mettre 2 arrêts sur une transaction.

2019.02.08 10:55:29 [INFO] : ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD
TRANSACTION_TRADITION_ADD
Symbole : RTS-3.19
Ticket de transaction : 12674810
Type d'offre : DEAL_TYPE_BUY
Billet de commande : 82646001
Type de commande : ORDER_TYPE_BUY
État de la commande : ORDER_STATE_STARTED
Type de temps de commande : ORDER_TIME_GTC
Expiration de la commande : 1970.01.01 00:00
Prix : 119700
Déclenchement du prix : 0
Stop Loss : 0
Prise de profit : 0
Volume : 1
Poste : 82646001
Position par : 0

2019.02.08 10:55:32 [INFO] : ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD
TRANSACTION_COMMERCIALE_ADDITIONNELLE
Symbole : RTS-3.19
Ticket de transaction : 12674810
Type d'offre : DEAL_TYPE_BUY
Billet de commande : 82646001
Type de commande : ORDER_TYPE_BUY
État de la commande : ORDER_STATE_STARTED
Type de temps de commande : ORDER_TIME_GTC
Expiration de la commande : 1970.01.01 00:00
Prix : 119700
Déclenchement du prix : 0
Stop Loss : 0
Prise de profit : 0
Volume : 1
Poste : 82646001
Position par : 0

 

Les événements de transaction(TRADE_TRANSACTION_DEAL_ADD) surviennent plusieurs fois régulièrement.

Heureusement, seule la plus récente se répète (au moins, je n'ai pas attrapé les plus anciennes).

Pour filtrer, il suffit de vérifier si le ticket de transaction est le même que le précédent.

 
Ilya Baranov:

Les événements de transaction(TRADE_TRANSACTION_DEAL_ADD) surviennent plusieurs fois régulièrement.

Heureusement, seule la plus récente se répète (au moins, je n'ai pas attrapé les plus anciennes).

Pour le filtrer, il suffit de vérifier si le ticket de transaction est le même que le précédent.

Pas plusieurs fois, mais par le nombre d'EAs qui travaillent actuellement dans le terminal.

Par conséquent, chaque EA doit traiter sa propre commande

case TRADE_TRANSACTION_DEAL_ADD:
      if((BuyOrder.ticket > 0) && (trans.order == BuyOrder.ticket))  // Buy order
      {
        //Сделка этого советника
      }
break;
 
prostotrader:

Pas plusieurs fois, mais par le nombre d'EAs qui travaillent actuellement dans le terminal.

Par conséquent, chaque EA doit traiter sa propre commande.

Votre code protège contre le fait qu'il s'agissait d'une transaction de cette EA.

TS et moi parlons des cas où OnTradeTransaction avec le typeTRADE_TRANSACTION_DEAL_ADD est appelé plusieurs fois pour une transaction, c'est-à-dire que les autres champs de MqlTradeTransaction contiennent exactement les mêmes données.

Cela signifie que dans votre cas, le code de traitement peut être exécuté plusieurs fois.

Ce n'est peut-être pas le cas de tous les courtiers. Mais ça arrive régulièrement chez tous les agents de change avec lesquels j'ai travaillé.

 
Ilya Baranov:

Votre code protège contre le fait qu'il s'agissait d'une transaction de cet EA.

TS et moi parlons des cas où OnTradeTransaction avec le typeTRADE_TRANSACTION_DEAL_ADD est appelé plusieurs fois pour une transaction, c'est-à-dire que les autres champs de MqlTradeTransaction ont exactement les mêmes données.

Cela signifie que dans votre cas, le code de traitement peut être exécuté plusieurs fois.

Ce n'est peut-être pas le cas de tous les courtiers. Mais cela arrive régulièrement avec tous les courtiers avec lesquels j'ai travaillé.

Je négocie à Otkryvashka en réel et je le teste en démo mais je n'ai pas de déclencheurs multiples.

Postez votre morceau de code pourTRADE_TRANSACTION_DEAL_ADD

 
Ilya Baranov:

Les événements de transaction(TRADE_TRANSACTION_DEAL_ADD) surviennent plusieurs fois régulièrement.

Heureusement, seule la plus récente se répète (au moins, je n'ai pas attrapé les plus anciennes).

Pour filtrer, il suffit de vérifier si le ticket de transaction est le même que le précédent.

Oui, merci ! Je viens de le faire après ce que j'ai vu.

En ce qui concerne le problème initial, j'ai mis un bordereau pour avoir le temps de pomper l'opération de suppression d'une commande et de l'ajouter à l'historique. Observé.

L'imperfection de la plate-forme à cet égard est très triste. Des choses qui devraient être regroupées en font des choses séparées.

prostotrader:

Pas plusieurs fois mais par le nombre d'EAs qui travaillent dans le terminal en ce moment.

C'est pourquoi chaque EA doit traiter sa propre commande.

Dans ce cas, je dois encore stocker le ticket de l'ordre du demandeur quelque part pour le comparer au ticket de la transaction. Et je veux juste me débarrasser de tout le stockage dans les variables locales et obtenir des informations uniquement du marché/terminal pour niveler les risques de l'infrastructure locale.
12345678910
Nouveau commentaire