OnTradeTransaction - page 7

 
fxsaber:

D'accord. Mais malheureusement dans MT5, contrairement à MT4, l'environnement de trading peut ne pas correspondre à la réalité. Par exemple, lorsqu'un ordre en attente est exécuté pendant quelques millisecondes, il peut ne se trouver nulle part. Et même OnTradeTransaction ne sera d'aucune aide ici.

Peut-être, OnTrade, tel que je le comprends est généré dans le terminal lui-même déjà sur la base des transactions.

Ou bien, voulez-vous dire que lorsqu'un ordre en attente se déclenche dans le gestionnaire OnTrade, aucune nouvelle position ouverte ne peut être détectée ?

 
Aleksey Mavrin:

Peut-être OnTrade, qui, si je comprends bien, est généré dans le terminal lui-même sur la base des transactions.

Ou voulez-vous dire qu'une nouvelle position ouverte peut ne pas être détectée dans le gestionnaire OnTrade lorsqu'un ordre en attente est déclenché ?

Dans toute fonction On. En ce sens, il y a un trou dans MT5. Il est peu probable qu'ils le réparent.

 
fxsaber:

Dans toute fonction On. En ce sens, il y a un trou dans le MT5. Il est peu probable qu'ils le réparent.

Si c'est le cas, c'est malheureux. Il perd pratiquement le sens de OnTrade. Nous devrons le vérifier. Idéalement, OnTrade devrait être appelé environ combien de fois lorsque l'ordre est déclenché :

pour les arrêts :

- un ordre de marché est créé et envoyé

- la commande en cours a été déplacée vers l'historique

- l'ordre a été exécuté, une transaction a été enregistrée

- l'ordre de marché a été déplacé vers l'historique

- poste créé

pour l'ordre Limit :

- ordre à cours limité activé transaction écrite

- La commande en cours a été déplacée dans l'historique

- le poste a été créé

En supposant que dans ce dernier cas, il devrait déjà y avoir une position et non les précédentes, il est logique qu'il n'y en ait pas, hein ?

J'ai appelé des fonctions pour vérifier tous les états de trading - transactions, positions et ordres - dans OnTrade. Jusqu'à présent, tout semble fonctionner correctement, mais je n'ai pas eu de transactions trop complexes.

 
 
fxsaber:

Pourquoi suis-je venu sur le forum, il y a tant de problèmes non résolus))

Merci, je vais m'en occuper. Bien que j'aie lu celui qui est surligné, je pense que ce n'est pas un problème mais une caractéristique. Dans les bases de données, et de manière générale, le concept de transaction et signifie que TOUTES LES

nécessaire pour effectuer une requête et maintenir l'exactitude de la base de données est fait, et après la transaction peut travailler avec la base de données, il n'y aura pas d'erreurs.

Si une action quelconque (et même pour écrire une ligne dans une table, il est parfois nécessaire d'en faire plusieurs et de s'assurer que les précédentes ont été effectuées avec succès)

Les modifications sont annulées et la transaction est rejetée. Là où je veux en venir, il ne faut probablement pas attendre de MT le niveau d'un SGBD :)

Dans ce cas, toutes les opérations intermédiaires doivent être surveillées et contrôlées, ce qui, là encore, donne plus de souplesse.

Mais tout me semble correct - d'abord, le serveur dit que l'ordre est terminé et le terminal le supprime dans l'archive, puis (plus tard) le serveur dit qu'il a ouvert une position et qu'il se peut qu'elle ne s'ouvre pas à cause d'une erreur, alors il devrait être à zéro.

Je vais le vérifier et rapporter les résultats en détail.

 
Aleksey Mavrin:

Mais tout me semble logique : le serveur signale d'abord que l 'ordre est exécuté, le terminal le supprime dans l'archive, puis (plus tard) le serveur signale qu'il a ouvert une position.

L'ordre n'est pas dans l'histoire et ne fait pas partie des ordres actuels. Et il n'y a pas de position. En d'autres termes, il n'y a rien.

 
Aleksey Mavrin:

Mais tout est logique pour moi - le serveur signale d'abord que l 'ordre est exécuté, le terminal le supprime dans l'archive, puis (plus tard) le serveur signale qu'il a ouvert une position, mais qu'elle peut ne pas s'ouvrir à cause d'une erreur, alors elle devrait être à zéro-zéro.

Je ne peux pas dire sur ce forum ou ailleurs où j'ai lu les posts de l'admin Renat (probablement Quick forum), mais il semble qu'il ait écrit que le seul contrôle que l'ordre passe sur le serveur est de fournir les exigences de marge, puis l'ordre "vole" à travers le connecteur vers la bourse, puis l'incertitude de l'exécution de l'ordre, en principe et possible, le serveur ne sait pas à quel prix l'ordre a été exécuté

 
En plus de l'exemple donné par fxsaber, dans la pratique il y a aussi un cas où il y a un ticket à la fois parmi les ordres et parmi les positions ouvertes. la situation dure aussi pendant plusieurs millisecondes (pas vérifié dans les derniers builds, cependant). le mécanisme de vérification doit être différent, donc soyez préparé à l'avance :)
 
Igor Zakharov:
En dehors de l'exemple donné par fxsaber, dans la pratique il y a un cas où il y a un ticket à la fois parmi les ordres et parmi les positions ouvertes. cette situation dure également pendant plusieurs millisecondes (pas vérifié dans les dernières constructions, cependant). le mécanisme de vérification devrait être différent, donc soyez préparé à l'avance :)

Cette situation est gérée de telle sorte que pour les EA de MT4, tout reste identique dans MT5 à ce qu'il était dans MT4. Mais avec les commandes fantômes - nous devons l'écrire.

 

Sur les robots "normaux", le cas que j'ai décrit, je n'ai rien remarqué du tout ; mais dans un cas, on m'a demandé de faire un système de sécurité : la condition était que les positions soient toujours verrouillées (soit avec des positions réelles, soit avec un ordre en attente), c'est-à-dire que le nombre de lots d'achat soit égal au nombre de lots de vente. C'est l'affaire qui m'a fait découvrir les nuances du comptage des ordres/positions/échanges dans un fiver.

La différence, telle que je me la suis expliquée :) est que le quatre, lorsqu'il reçoit une réponse du courtier, synchronise d'abord ses "tables" avec les ordres ouverts et l'historique, puis informe l'utilisateur de la réponse du courtier. Le cinq nous diffuse immédiatement cette réponse, et en même temps corrige ses "tables" (et tous les programmes mql lisent les données de ces "tables"). C'est le moment que nous attrapons sur le chronomètre à millisecondes. Mais alors, pourquoi ne l'attrapons-nous pas dans le testeur ?

En général, je l'ai supporté...

Raison: