Question sur la fonction OnTradeTransaction - page 4

 
Mikalas:

C'est parce que la bourse n'a pas de cuisine (seulement des commissions) et que le FOREX a des millions d'adeptes MMM,

il y a peut-être 100 dollars, mais tout le monde en a ! De l'argent énorme, il y a de quoi compter ! :)

Je ne comprends pas MetaQuotes )

Pour les cuisines du forex, il existe un excellent terminal MT4.

De nombreux forex ne fournissent jamais d'accès via MT5, ils n'en ont pas besoin, bordel de merde.

Est-il impossible depuis tant d'années de réaliser un terminal proche des échanges ?

Si nous avons un bon terminal, il y aura beaucoup de clients qui voudront fournir des services MT5.

 
Serj_Che:

Je ne comprends pas MetaQuotes )

Pour les cuisines du forex, il existe un excellent terminal MT4.

De nombreux forex ne fournissent jamais d'accès via MT5, ils n'en ont pas besoin, bordel de merde.

Est-il impossible, après tant d'années, de réaliser un terminal proche des échanges ?

Si nous avons un bon terminal, il y aura beaucoup de clients qui voudront fournir des services MT5.

Il ne s'agit pas de MQ, il s'agit de courtiers.

Les courtiers profitent du fait que les clients effectuent des transactions - plus de transactions - plus de commissions.

Le robot ne fera que des "transactions correctes", et en plaçant des ordres "à la main", les gens sont très...

Le robot ne fera que des transactions "correctes" et en passant un ordre manuel, les gens font très souvent des erreurs (j'ai moi-même fait cette erreur de nombreuses fois),

Vous vous faites prendre, vous jurez, vous fermez l'ordre avec une perte, vous voulez le récupérer, vous vous êtes trompé à nouveau, etc.

Et le courtier et la bourse ont reçu une commission :)

Ainsi, pour la bourse et surtout pour le courtier, QUIK est la mère patrie.

 
Mikalas:

Vasily, y aura-t-il une réponse ?

Je ne pense pas.

Est-ce que j'ai gagné ?

Je vous donnerai une réponse ce soir. Je ne peux pas en ce moment.
 
C-4:

Ne compliquez pas les choses. Il n'est pas nécessaire d'utiliser l'asynchronie pour négocier sur FORTS. Pour commencer, jetez un coup d'œil à cet article, chapitre 3 : "Les bases des opérations asynchrones". Ce n'est pas grand-chose, c'est très basique, mais c'est suffisant pour commencer à l'étudier. Le code décrit ici est 100% asynchrone, mais cela ne l'empêche pas de fonctionner en mode synchrone sans recevoir toutes sortes d'événements OnTradeTransaction et autres.

La solution doit être basée sur votre tâche. Dans MetaTrader 5, vous n'avez qu'une seule position active à un moment donné, alors faites-y attention. Il n'est pas nécessaire de consulter l'historique des commandes. Si vous avez toujours besoin de l'historique des commandes, vous devez clarifier votre objectif.

Non, Vasily, tu n'as pas bien compris mon but. Je ne vais pas écrire quoi que ce soit ou faire du commerce sur FORTS, je viens juste de commencer à apprendre mql5. J'ai commencé à lire cet article plus tôt. Mais je n'ai pas lu plus de 2 pages et j'ai abandonné. Je ne pense pas en avoir besoin, je suis moi-même un NT. Mais une explication claire de la différence entre OrderSend et OrderSendAsync est utile. C'est à peu près ce à quoi je m'attendais.

Si nous sautons la soumission asynchrone des ordres et utilisons OnTradeTransaction pour suivre ce qui se passe sur le compte, cela n'améliorerait-il pas les performances de l'EA ?

C'est une chose d'effectuer un contrôle à chaque tic, et c'en est une autre de ne le faire que s'il y a eu un changement dans le compte. Ai-je tort ? L'ordre en attente a été activé, nous avons des informations à son sujet. Une position est fermée, nous pouvons analyser le résultat de sa fermeture. Il n'y a que quelques contrôles pendant la période allant de l'ouverture à la fermeture d'une position. Et en revanche, il y a des contrôles sur chaque tic...

Voici une autre question : Pour déterminer le profit d'une position, il existe la fonction PositionGetDouble(POSITION_PROFIT), mais pour déterminer le profit d'une position fermée, seule la fonction OrderCalcProfit() possède un tas de paramètres qui doivent d'abord être obtenus de cette transaction. Ou peut-être que je suis tellement novice en matière de mql5 que je ne trouve pas de solution adéquate ?

Si ça ne vous dérange pas...

 
AlexeyVik:

Non, Vasily, vous avez mal compris mon objectif. Je ne vais pas encore écrire quoi que ce soit ou faire du commerce sur FORTS, je viens juste de commencer à apprendre mql5. J'ai commencé à lire cet article plus tôt. Mais je n'ai pas lu plus de 2 pages et j'ai abandonné. Je ne pense pas en avoir besoin, je suis un NT moi-même. Mais une explication claire de la différence entre OrderSend et OrderSendAsync est utile. C'est à peu près ce à quoi je m'attendais.

Si nous abandonnons la soumission asynchrone des ordres et que nous utilisons toujours OnTradeTransaction pour suivre ce qui se passe sur le compte, cela ne va-t-il pas améliorer les performances de l'EA ?

C'est une chose d'effectuer un contrôle à chaque tic, et c'en est une autre de ne le faire que lorsqu'il y a un changement dans le compte. Ai-je tort ? L'ordre en attente a été activé, nous avons des informations à son sujet. Une position est fermée, nous pouvons analyser le résultat de sa fermeture. Il n'y a que quelques contrôles pendant la période allant de l'ouverture à la fermeture d'une position. Et en revanche, il y a des contrôles sur chaque tic...

Voici une autre question : Pour déterminer le profit d'une position, il existe la fonction PositionGetDouble(POSITION_PROFIT), mais pour déterminer le profit d'une position fermée, seule la fonction OrderCalcProfit() possède un tas de paramètres qui doivent être obtenus au préalable de cette transaction. Ou peut-être que je suis tellement novice en matière de mql5 que je ne trouve pas de solution adéquate ?

Si ça ne pose pas trop de problèmes...

OrderCalcProfit ne vous aidera pas.

Vous devez calculer le prix moyen de tous les ordres (in) et le prix moyen de tous les ordres (out),

alors le profit d'une position fermée peut être calculé.

Nous devrons nous pencher sur l'histoire.

 
Mikalas:

OrderCalcProfit ne vous aidera pas.

Vous devez calculer le prix moyen de tous les ordres (in) et le prix moyen de tous les ordres (out),

Nous pouvons alors calculer le bénéfice d'une position fermée.

Nous devrons enquêter sur l'histoire.

En principe, je le comprends (même si je ne sais pas encore comment le faire), mais dans ce cas, seule la dernière position fermée est importante pour moi. Apparemment, cela convient mieux au cas où le poste a été pourvu. Mais ma tâche est différente.

J'ai décidé de réécrire mes hiboux mql5 avec martin. Il est sur le marché en permanence et ouvre le prochain trade vers la dernière position...

Oups... c'est dire à quel point il est utile de communiquer sur le forum. Après tout, si la position ne peut être inversée que lorsque l'ordre en suspens est activé, ou clôturée à la prise, je ne me soucie pas de la taille du profit ou de la perte. Eh bien, si le dernier genou donne un moins, alors vous n'aurez besoin de rien... Il suffit de connaître le type de position fermée... Et ceci peut être écrit dans une variable de niveau global dans le handler OnTradeTransaction avec le type de transaction TRADE_TRANSACTION_DEAL_ADD et avec le type de transaction TRADE_TRANSACTION_HISTORY_ADD ou avec la condition que PositionsTotal est égal à zéro pour mettre le prochain premier ordre de la série... Je l'ai noté pour moi, pour ne pas l'oublier :))))



 
papaklass:

...C'est-à-dire que la logique de votre algorithme doit être basée sur le CHANGEMENT DE L'ENVIRONNEMENT DE TRADING, et non sur le traitement de fonctions ou d'événements.

3 La fréquence de contrôle de l'environnement de trading (au tick, à la barre, au timer, etc.) doit correspondre à la logique de votre TS. C'est-à-dire à quelle vitesse le changement d'environnement commercial doit-il être traité ? Si la logique de votre TS exige de traiter le changement le plus rapidement possible, alors vous ne pouvez pas éviter de le vérifier à chaque tick...

Et si votre EA est multi-devises ?
 
papaklass:

1. La fonction OrderSendAsync() est utilisée lorsque plusieurs commandes doivent être envoyées en UNE seule fois, une sorte d'envoi par lot. Avec l'envoi par lot, si vous attendez que le serveur réponde à chaque commande (en utilisant la fonction OrderSend()), il y aura un décalage total important dans l'envoi de l'ensemble du lot. Pendant ce laps de temps, le marché peut changer de manière significative ! Pour éviter ce décalage, nous avons introduit la fonction OrderSendAsync(). Vous devez clairement comprendre cela.

Si vous n'avez pas besoin d'envoyer des commandes par lots, il est inutile d'utiliser la fonction OrderSendAsync().

Le moyen le plus fiable de déterminer si un ordre, une commande, etc. a été déclenché, est de surveiller votre environnement de négociation. - est le suivi de votre environnement commercial, et non le déclenchement d'une fonction ou d'un événement. Une fonction ou un événement peut fonctionner, mais cela ne change pas nécessairement votre environnement commercial. Pourquoi ? Car une erreur peut simplement se produire pendant l'exécution de la fonction.

Ainsi, la logique de votre algorithme doit être basée sur le CHANGEMENT DE VARIABLE, mais pas sur le traitement de fonctions ou d'événements.

3. la fréquence de vérification de l'environnement commercial (sur un tick, sur une barre, par timer, etc.) doit correspondre à la logique de votre TS. En d'autres termes, à quelle vitesse les modifications de l'environnement commercial doivent-elles être traitées ? Si la logique de votre TS exige de traiter un changement le plus rapidement possible, vous ne pouvez pas éviter de le vérifier à chaque tick.

Alexander, merci pour vos commentaires.

Je le comprends seulement pour comprendre que je n'en ai pas besoin jusqu'à présent. Pour l'instant, la fonction OrderSend me suffit.

2) Oui, je suis d'accord pour dire que l'état le plus précis ne peut être déterminé qu'en surveillant l'ensemble de l'environnement à chaque instant. Mais avoir un tel gestionnaire d'événement pour l'ignorer... Eh bien, je ne fais qu'expérimenter. Je comprends parfaitement votre désir de m'aider à le rendre plus fiable, mais mon objectif est différent. Je n'ai pas besoin de ce conseiller expert de façon urgente, et je ne l'écris pas sur commande.

3. Peut-être que dans la version finale de l'EA, je reviendrai aux tests sur chaque tick, mais pour l'instant...

La question était de savoir si nous pouvions faire confiance au gestionnaire d'événement OnTradeTransaction alors que la documentation nous met en garde contre lui.

En outre, les transactions peuvent être perdues lors de leur acheminement du serveur au terminal.

Et dans quels cas il est préférable de ne pas faire confiance, et dans quels cas vous devez l'étayer avec quelque chose.

Je suis très reconnaissant envers tout le monde, Vasiliy, Michael et toi Alexander. Je serai très heureux et vous remercie encore si vous partagez d'autres réflexions.

 
papaklass:

C'est exactement la question à laquelle Vasily et moi-même avons répondu.

Pensez-y, si le travail de la fonction OnTradeTransaction() doit tout de même être vérifié, il peut être préférable de vérifier l'environnement de négociation tout de suite plutôt qu'après le traitement de la fonction OnTradeTransaction(). Cependant, c'est une question de goût.

Et dans le fil de discussion suivant, Renat a promis de travailler avec la fonction et peut-être que dans les prochaines versions, nous aurons une amélioration de cette fonction.

Mais nous nous concentrons toujours sur le placement asynchrone des commandes. Dans ce cas, nous n'avons aucune raison de perdre une commande parmi des centaines d'autres. Et pourtant, Michael affirme qu'en six mois, avec un nombre incroyablement élevé de commandes, il n'a pas perdu une seule transaction. Et quelle est la probabilité de perdre une transaction si l'ordre est placé à l'aide de la fonction OrderSend() ?

Et si une amélioration est prévue, c'est une raison de plus de s'en inquiéter. Ou est-ce que je me trompe encore ?

 
denkir:
А если советник мультивалютный?


papaklass:

Ce que vous voulez que je dise n'est pas clair.

Un argument contre le modèle événementiel...