Traitement des transactions (OnTradeTransaction) - page 6
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
Bon après-midi.
Personne n'est intimidé par qui que ce soit.
Vous n'avez pas switch(trans.type)
Bien sûr, le cas donné est dans switch(trans.type). Comme il y avait un autre cas, je n'ai pas voulu montrer tout le code afin de ne pas le surcharger d'informations inutiles.
fxsaber , merci pour l'exemple !
Alexey, c'est exactement la même chose. J'utilise 2 robots différents pour trader sur le même symbole en mode compensation. Les 2 posts que vous avez cités se complètent.
Il est intéressant de résoudre le problème en partant du principal déclencheur de changement - onTradeTransaction.
Total des problèmes actuels rencontrés :
1. deal_add se déclenche, mais pas de pose. Aucune idée jusqu'à présent.
2. deal_add est déclenché, mais l'ordre est dans la troisième dimension. Mettre un slip, ces deux derniers jours semble aider. L'ordre parvient à atteindre l'histoire en 1 seconde. Je n'ai pas de robots de trading à haute fréquence et je n'utilise pas d'ordres au marché, cette solution serait donc appropriée.
3. deal_add est déclenché 2 fois, c'est-à-dire qu'un seul et même deal_add est déclenché 2 fois. Ce problème peut être résolu en vérifiant le ticket d'une transaction précédente et en le comparant à celui de la transaction actuelle.
Il reste le point 1, avec des explications à ce sujet.
Hier, j'ai réglé le paramètre sell_limit, cela a fonctionné, deal_add est arrivé, mais la position n'est pas apparue et nous avons ouvert un ordre stop pour rien. J'ai commencé à regarder la description de la transaction et j'ai vu que le type de transaction est DEAL_TYPE_SELL mais que le type d'ordre est ORDER_TYPE_BUY. En même temps, le ticket de commande est le nôtre. Ça ne semblait pas très logique. J'ai décidé de vérifier que le type d'ordre et le type de transaction doivent être les mêmes dans OnTradeTransaction, que le type d'ordre et le type de transaction doivent être les mêmes.
J'ai mis le robot sur la démo et j'ai obtenu une autre transaction similaire mais cette fois la position a changé. Mais à cause de notre contrôle, l'ordre d'arrêt n'a pas été exécuté. Que se passe-t-il ?
Je vous le dis tout de suite, c'est ce qui arrive dans le terminal. Sans que je l'invente.
Hier, j'ai placé sell_limit, il s'est déclenché, deal_add est arrivé, mais aucune position n'est apparue et nous avons ouvert des ordres stop pour rien. J'ai commencé à examiner la description de la transaction et j'ai vu que le type de transaction est DEAL_TYPE_SELL et que le type d'ordre est ORDER_TYPE_BUY. En même temps, le ticket de commande est le nôtre. Ça ne semblait pas très logique. J'ai décidé de vérifier que le type d'ordre et le type de transaction doivent coïncider dans OnTradeTransaction sur la transaction deal_add.
Mais il est utile de relire l'aide"Structure des transactions commerciales" pour savoir quels champs sont remplis pour le type deal_add.
Et de prendre les propriétés de la commande non pas à partir de la transaction (où elles ne sont pas remplies, mais où les zéros correspondent aussi à certaines valeurs dans l'enum-type), mais à partir de la commande elle-même, si elle est disponible à ce moment-là (et non pas dans le processus de transition des commandes vers l'historique).
Il est ainsi plus facile d'analyser l'évolution de la situation.
Vous pouvez ajouter que, parallèlement aux transactions, l'état des positions, les ordres en cours et l'historique des transactions peuvent être enregistrés. L'ensemble du tableau sera alors disponible.
C'est là que l'aide"Structure d'une transaction commerciale" mérite d'être relue - en ce qui concerne les champs à remplir pour le type deal_add.
Et de prendre les propriétés de la commande non pas à partir de la transaction (où elles ne sont pas renseignées, mais où les zéros correspondent aussi à certaines valeurs de l'enum-type), mais à partir de la commande elle-même, si elle est actuellement disponible (et pas en cours de transition des commandes vers l'historique).
Je suis d'accord, j'en étais conscient, mais je n'y ai pas prêté attention. Merci de me le rappeler.
Toutefois, le problème de la non-apparition d'une position dans un cas et de son apparition dans un autre demeure et n'est pas clair.
Илья Ребенок:
Cependant, le problème de la position n'apparaissant pas dans un cas et apparaissant dans l'autre reste et n'est pas clair.
Le poste a été enregistré dans la transaction deal_add, mais le poste n'existait pas auparavant et il n'est pas apparu ? Il faut régler ce problème.
Le poste a été enregistré dans la transaction deal_add, mais le poste n'existait pas auparavant et n'a pas été affiché ? Il faut régler ce problème.
la position n'était pas là avant
la position n'était pas là avant
Y avait-il un ticket de position dans la transaction ?
Y avait-il un ticket de position dans la transaction ?
Dans le message ci-dessus, j'ai dû faire un petit malentendu. Il y avait une position, puis elle a été fermée par des ordres stop. C'est-à-dire que le nombre de positions est devenu 0. Ensuite, une transaction a été déclenchée, mais la position n'est pas apparue.
Je pense que c'est ce que vous voulez dire. La transaction contenait des informations sur le ticket de la position, mais ce ticket = ticket de la commande précédente. Comme il devrait l'être en mode filet, si je comprends bien.
Position: 82675534Dans le message ci-dessus, j'ai dû faire un petit malentendu. Il y avait une position, puis elle a été fermée par des ordres stop. C'est-à-dire que le nombre de positions est devenu 0. Ensuite, une transaction a été déclenchée, mais la position n'est pas apparue.
Je pense que c'est ce que vous voulez dire. La transaction contenait des informations sur le ticket de la position, mais ce ticket = ticket de la commande précédente. Comme en général, il devrait être en mode filet, si je comprends bien.
Si la position sur le symbole (cumulée, tous robots et trades manuels confondus) est devenue 0.0, alors la prochaine transaction ouvrira (DEAL_ENTRY_IN) une nouvelle position, avec un nouveau ticket (==ticket de l'ordre).
En fait, il me semble que lors de la compensation, il n'est pas nécessaire de regarder la position du tout - chaque robot doit tenir compte de "sa" position - comme le résultat des transactions sur ses ordres.
La présence de positions et de drapeaux DEAL_ENTRY ne doit en aucun cas intervenir dans la logique.
Il suffit de regarder la magie et le commentaire des nouvelles transactions et des ordres en cours pour identifier les propres/étrangers.
Le code de travail a montré. C'est exactement la même chose.
Essayer de résoudre le problème via OnTradeTransaction est une mauvaise idée compte tenu du nombre d'embûches. Ce qui, dans une tâche particulière, peut parfois encore être contourné. Mais si vous modifiez légèrement la tâche, toute la logique est rompue pendant la mise en œuvre de OnTradeTransaction.
Les développeurs ont créé un modèle de commerce événementiel mais ils n'ont pas fourni un seul exemple fonctionnel. Parce que c'est un trou du cul complet ce que le code verse et combien ça dépend de chaque exemple.
Par conséquent, je vous recommande d'examiner les opérations de trading synchrone et la fonction OnTrade. Tout y est beaucoup plus facile et la logique est très souple pour les changements. En outre, il est plus fiable.
Le passage à Async+Transactions est comparable au passage du langage de haut niveau à l'assembleur. C'est-à-dire que cela devrait être fait à la toute dernière étape de la création du TS, lorsqu'il est COMPLÈTEMENT étudié, prêt pour le VRAI et que la dernière chose est d'accélérer les opérations de trading SANS changer la logique de trading.