OnTradeTransaction - page 2
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
D'un côté, oui. D'autre part, qu'en est-il des cas où une demande a été envoyée au serveur, mais où l'opération n'a pas encore été exécutée ? Comment pouvons-nous savoir dans quel état nous sommes si nous n'avons qu'une liste d'ordres et de positions (et l'historique du compte) ?
Ce problème ne se pose pas dans MT4, car toutes les opérations de trading y sont synchrones. Mais le résultat est une performance plus lente.
Le fait que les opérations asynchrones soient plus rapides que les opérations synchrones est un mythe qui provient de l'ignorance de ce qui se passe. Les opérations asynchrones ont un cycle complet d'exécution d'une action commerciale divisé en plusieurs parties, alors que les opérations synchrones n'ont qu'un seul cycle. L'opération asynchrone nécessite également la réponse du serveur, l'exécution sur l'échange est la même, c'est-à-dire que le temps total requis pour l'opération asynchrone et synchrone est presque le même. L'avantage des ordres asynchrones est la possibilité de les envoyer simultanément, c'est-à-dire qu'il est possible d'envoyer deux ou plusieurs ordres presque en même temps. C'est ce qui permet d'atteindre une vitesse de fonctionnement élevée (au total). Tous les conseillers experts n'ont pas besoin du mode d'envoi asynchrone. Tout d'abord, il est nécessaire pour divers opérateurs d'arbitrage où vous devez acheter deux ou plusieurs symboles en même temps, ou pour les algorithmes HFT. Par exemple, le robot HFT peut envoyer un ordre pour entrer sur le marché, et dans 3-4 msec il peut envoyer l'ordre opposé, auquel cas il est trop long d'attendre la réponse du serveur sur le premier ordre, il a donc besoin du mode d'envoi asynchrone - sans attendre le résultat. Dans la grande majorité des EA, ces vitesses ne sont pas nécessaires.
Vous ne savez pas non plus comment faire. Vous avez déjà écrit des dizaines de pages sur OnTradeTransaction, mais vous n'avez pas compris une chose : OnTradeTransaction est une fonction de service pour résoudre des tâches spécifiques, vous ne pouvez pas l'utiliser dans le trading comme vous le faites. Et puis des types intelligents lisent vos articles et créent des fils de discussion similaires : "Pourquoi OnTradeTransaction n'est-il pas garanti ?" - parce qu'un conseiller expert ne devrait pas créer son environnement de négociation par le biais de OnTradeTransaction, comme vous le faites, mais se fier uniquement à ce qui est disponible dans le système, en particulier dans l'historique des ordres et des transactions.
Et c'est là que Ostap se trompe.....
Si vous avez une rancune personnelle à mon égard, il n'est pas nécessaire de l'introduire dans une discussion.
de problèmes techniques dans lesquels vous êtes "très bien versé"...
C'est vous qui trompez les gens avec votre arrogance théâtrale !
Et c'est là qu'Ostap a mal tourné.....
Si vous avez une rancune personnelle à mon égard, il n'est pas nécessaire de l'introduire dans une discussion.
de problèmes techniques dans lesquels vous êtes "hautement compétent"...
Vous ne faites que tromper les gens avec vos théories affirmées !
Misha, bonjour ! Comment s'est passé ton voyage en Formule 1 ? Comment était le temps à Sochi ?
Salut !
Super ! Je me suis baigné dans la mer (l'eau était à 24 degrés).
Salut !
Super ! Je me suis baigné dans la mer (l'eau était à 24 degrés).
Cool, c'est de l'eau très chaude !
Sérieusement, je n'ai rien à vous reprocher. Si vous voulez argumenter sur le fond - bienvenue. De plus, je n'ai aucune envie d'enseigner à quelqu'un. Chacun a son propre vélo à roues carrées.
Si le délai entre l'envoi de l'ordre et le prochain signal d'entrée sur le marché dépasse le délai d'exécution de l'ordre, il n'y a rien à faire. La logique ici est simple : nous envoyons un ordre asynchrone, sortons du fil et l'oublions. Nous attendons le moment suivant pour vérifier le signal. Si, à ce moment-là, l'environnement commercial n'a pas changé, le conseiller expert recherche un signal pour entrer à nouveau sur le marché et répète l'ordre d'entrée sur le marché. Si, au contraire, tout s'est bien passé et que l'ordre a été exécuté, le conseiller expert se rendra compte qu'il a une position après avoir analysé l'environnement et n'ouvrira pas à nouveau une nouvelle position. C'est-à-dire que dans cette approche, la condition du conseiller expert est garantie pour être cohérente avec l'environnement du marché.
La situation est plus compliquée dans le trading à haute fréquence, où un nouveau signal peut survenir après un temps comparable à l'exécution d'un ordre (6-100 msec). Dans ce cas, vous ne pouvez pas vous passer du verrouillage. Le conseiller expert doit se souvenir de l'heure de l'envoi du dernier ordre. Si une erreur se produit dans OnTransaction, le verrouillage est réinitialisé et le conseiller expert peut à nouveau effectuer des transactions.
Il faut noter que le OnTradeTransacton que tant de gens aiment prier n'aide pas à HFT. Un nouveau signal d'entrée peut arriver plus rapidement que la réponse concernant l'exécution réussie d'une transaction dans OnTradeTransaction. Le blocage est nécessaire, que vous utilisiez ou non OnTradeTransacton.
Comment, me direz-vous, pouvons-nous contrôler les erreurs survenant dans OnTradeTransaction ? Vous pouvez répondre par une contre-question : Comment allez-vous modifier la logique de trading du conseiller expert à la volée lorsqu'une erreur se produit? - Vous ne pouvez pas. Des erreurs se produisent si vous ne faites pas les vérifications appropriées avant (présence d'argent, volume, etc., etc.). Mais une fois qu'il s'est produit, vous ne pourrez pas le corriger. Par conséquent, la meilleure chose que vous puissiez faire dans OnTradeTransaction, est d'imprimer cette erreur dans le journal (pour corriger la logique du conseiller expert plus tard), et de supprimer le verrou, s'il est utilisé. Pour cela et rien d'autre, il faut utiliser OnTradeTransaction.
Maintenant, divers adeptes de Mikalas vont arriver en courant et commencer à me jeter des tomates - laissez-les faire. Mais j'ai toujours répété qu'une logique de trading fiable ne peut être organisée que si elle est basée sur l'environnement de trading du terminal. Tout le reste - ne fonctionne pas.
Je ne comprends pas bien ce que le temps entre les signaux a à voir avec cela ? Chaque signal de trading a son heure d'enregistrement. Une fois le signal enregistré (apparu), il est nécessaire d'effectuer une opération de trading. En conséquence, le conseiller expert envoie un ordre de transaction au serveur et poursuit son travail. L'ordre n'a pas encore été exécuté par le serveur. Un nouveau tic arrive. Le conseiller expert réanalyse son état et découvre qu'il existe un signal d'ouverture, mais qu'il n'y a pas de position (ou d'ordre) correspondante parmi les ordres de travail.
Ma question est la suivante: comment l'Expert Advisor peut-il déterminer sans utiliser les données de OnTrade ou OnTradeTransaction pourquoi il n'y a pas de position ? Il peut y avoir plusieurs raisons :
1. La demande d'ouverture a été envoyée au serveur, mais le serveur n'a pas encore donné de réponse sur le résultat de l'exécution de l'ordre. Nous devons attendre la réponse.
2. La demande n'a pas encore été envoyée au serveur. Les commandes doivent être envoyées.
3. La demande a été envoyée, le serveur répond que l'ordre ne peut pas être exécuté. Le message d'erreur doit être traité et une décision doit être prise quant à la marche à suivre.
4. La requête a été envoyée, mais le serveur ne répond pas pendant un long moment (chacun définit lui-même ce temps, le mien est de 1 minute) (timeout).
Je ne vois pas de solution sans utiliser OnTrade ou OnTradeTransaction. Mais vous prétendez qu'il y en a une. Veuillez expliquer lequel. Parce qu'il est étrange de parler de verrouillage de threads dans MQL4/5 - il n'y a pas deux ou plusieurs threads, il n'y a qu'un seul thread. De plus, vous opérez avec des expressions telles que "si tout va bien et que l'ordre est exécuté", mais vous n'expliquez pas comment cela est déterminé. Et c'est là l'essence de ma question.
On ne voit pas très bien ce que le temps entre les occurrences des signaux a à voir avec cela ? Chaque signal de trading a son propre temps d'enregistrement. Une fois le signal enregistré (survenu), il est nécessaire d'effectuer une opération de trading. En conséquence, le conseiller expert envoie un ordre de transaction au serveur et poursuit son travail. L'ordre n'a pas encore été exécuté par le serveur. Un nouveau tic arrive. Le conseiller expert réanalyse son état et découvre qu'il existe un signal d'ouverture, mais qu'il n'y a pas de position (ou d'ordre) correspondante parmi les ordres de travail.
Ma question est la suivante: comment l'Expert Advisor peut-il déterminer sans utiliser les données de OnTrade ou OnTradeTransaction pourquoi il n'y a pas de position ? Il peut y avoir plusieurs raisons :
1. La demande d'ouverture a été envoyée au serveur, mais le serveur n'a pas encore donné de réponse sur le résultat de l'exécution de l'ordre. Nous devons attendre la réponse.
2. La demande n'a pas encore été envoyée au serveur. Les commandes doivent être envoyées.
3. La demande a été envoyée, le serveur répond que l'ordre ne peut pas être exécuté. Le message d'erreur doit être traité et une décision doit être prise quant à la marche à suivre.
4. La demande a été envoyée, mais le serveur ne répond pas (timeout) pendant un long moment (chacun définit lui-même ce temps, le mien est de 1 minute).
Je ne vois pas de solution sans utiliser OnTrade ou OnTradeTransaction. Mais vous prétendez qu'il y en a une. Veuillez expliquer lequel. Parce qu'il est étrange de parler de verrouillage de threads dans MQL4/5 - il n'y a pas deux ou plusieurs threads, il n'y a qu'un seul thread. De plus, vous opérez avec des expressions telles que "si tout va bien et que l'ordre est exécuté", mais vous n'expliquez pas comment cela est déterminé. Et c'est là l'essence de ma question.
Je ne parle pas de bloquer le fil de discussion, mais de bloquer l'envoi de l'ordre de transaction.
Une double question: supposons qu'un conseiller expert ait déterminé la raison pour laquelle un ordre de transaction ne peut être exécuté (le marché est fermé, il n'y a pas d'argent, etc.), que faire ensuite? Comment le conseiller expert va-t-il améliorer la situation ? Cela va-t-il ajouter de l'argent sur le compte ou ouvrir le marché ? En quoi le fait de connaître la cause de l'erreur d'envoi du dernier ordre aidera-t-il le conseiller expert à poursuivre ses transactions ?
Il ne s'agit pas de bloquer le flux, mais de bloquer l'envoi de l'ordre de transaction.
Voici la question : si le serveur renvoie une erreur d'exécution de la commande, comment pouvons-nous le savoir pour débloquer la possibilité d'envoyer une deuxième commande ? Encore une fois, si OnTrade et OnTradeTransaction ne sont pas utilisés.
Autre question: Supposons que le conseiller expert ait déterminé la raison pour laquelle un ordre ne peut être exécuté (le marché est fermé, il n'y a pas d'argent, etc.), que faire ensuite? Comment le conseiller expert va-t-il améliorer la situation ? Cela va-t-il ajouter de l'argent sur le compte ou ouvrir le marché ? En quoi le fait de connaître la cause de l'erreur du dernier ordre aidera-t-il le conseiller expert à poursuivre ses transactions ?
Cela vous aidera beaucoup. Nous laisserons de côté le manque d'argent, car le conseiller expert doit déterminer ce point avant d'envoyer un ordre de transaction et en informer le trader par un message (ou par un autre moyen). Par conséquent, l'ordre de transaction n'est pas envoyé du tout.
Le message d'erreur peut nous indiquer si nous devons continuer à essayer d'envoyer des commandes. Par exemple, si le marché est fermé, il n'est pas nécessaire de renvoyer la demande immédiatement. Vous devez arrêter le trading pendant un certain temps (déterminé par le développeur du conseiller expert), et seulement ensuite envoyer une nouvelle demande (si le signal de trading est toujours actif). Si une requote se produit, vous pouvez envoyer une nouvelle demande immédiatement. S'il y a eu une erreur dans le réglage des stops (le niveau d'arrêt ou le niveau de gel a changé pendant l'envoi de l'ordre), les stops sont corrigés en fonction des nouvelles données et une nouvelle demande est envoyée immédiatement.
Ainsi, la connaissance d'une erreur de trading (en général, n'importe quelle erreur) et son traitement correct est une condition préalable au fonctionnement de tout programme "normal".
Voici la question : si le serveur renvoie une erreur d'exécution de l'ordre, comment puis-je le savoir afin de débloquer la possibilité de renvoyer l'ordre ? Encore une fois, si OnTrade et OnTradeTransaction ne sont pas utilisés.
Très utile. Nous laisserons le manque d'argent, car le conseiller expert devrait détecter ce point avant d'envoyer un ordre de transaction et en informer le trader par un message (ou par un autre moyen). Par conséquent, l'ordre de transaction n'est pas envoyé du tout.
Le message d'erreur peut nous indiquer si nous devons continuer à essayer d'envoyer des commandes. Par exemple, si le marché est fermé, il n'est pas nécessaire de renvoyer la demande immédiatement. Vous devez arrêter le trading pendant un certain temps (déterminé par le développeur du conseiller expert), et seulement ensuite envoyer une nouvelle demande (si le signal de trading est toujours actif). Si une requote se produit, vous pouvez envoyer une nouvelle demande immédiatement. S'il y a eu une erreur dans le réglage des stops (le niveau d'arrêt ou le niveau de gel a changé pendant l'envoi de l'ordre), les stops sont corrigés en fonction des nouvelles données et une nouvelle demande est envoyée immédiatement.
Ainsi, la connaissance d'une erreur de négociation (en général, toute erreur) et son traitement correct sont une condition nécessaire au fonctionnement de tout programme "normal".
Si le marché est fermé, nous devons le vérifier avant d'envoyer l'ordre.
Dans les autres cas, l'ordre de transaction doit être renvoyé. Ainsi, toutes les erreurs peuvent être divisées en deux catégories :
Si un conseiller expert a reçu une erreur du deuxième type, ses actions doivent être toujours les mêmes et ne dépendent pas du type d'erreur : il doit répéter son ordre de transaction en espérant qu'il sera exécuté cette fois-ci. Avant d'envoyer un ordre de transaction, le conseiller expert doit contrôler le premier type d'erreurs. Par conséquent, le conseiller expert n'a pas besoin de corriger son comportement en fonction du type d'erreur renvoyé dans OnTradeTransaction. Toutefois, vous pouvez informer l'utilisateur des erreurs survenant dans OnTradeTransaction et réinitialiser le verrou lors de l'exécution d'une nouvelle opération commerciale si la transaction précédente s'est soldée par une erreur du deuxième type. Dans ce cas, si OnTradeTransaction ne se produit pas pour une raison quelconque, le verrou doit quand même être réinitialisé par un délai d'attente. Ainsi, il importe peu que OnTradeTransaction arrive ou non, simplement qu'avec OnTradeTransaction les ordres répétés seront exécutés à la vitesse la plus rapide possible.
s.w. FreezeLevel doit également être analysé avant l'envoi de la commande.