Est-il possible d'implémenter une comptabilité FIABLE de la structure des positions agrégées dans MT5 ? - page 18
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
Vos affirmations audacieuses en diverses occasions (mes qualifications, la situation du MC, etc.) réduisent quelque peu l'intérêt de votre opinion, ne pensez-vous pas ?)) D'une certaine manière, il n'y a aucun intérêt à vous répondre - pourquoi répondre aux déclarations d'une personne clairement inadéquate ? )))
Pour commencer, arrêtez de confondre les hallucinations avec la réalité - nous allons parler.
C'est bon, je me suis calmé.
De quoi allons-nous parler ?
J'ai déjà préparé mon stylo et mon carnet.
>> Je vous écoute, monsieur.
Je viens de clarifier. Puisque le niveau SL n'est garanti en aucune façon et qu'il est exécuté sur les marchés uniquement à la demande du marché, l'obligation de ne pas atteindre le niveau TP n'est pas nécessaire. Juste avant d'exécuter le SL sur le marché, le serveur d'exécution (Dukascopy) supprime le niveau du TP (même s'il est dans le pick). C'est le point qui, malheureusement, ne peut pas être mis en œuvre par le trader dans MT5, même s'il dispose d'une connexion parfaite au serveur commercial. Et c'est, en effet, VRAIMENT IMPOSSIBLE sur le MT5.
Voici comment nous voyons la solution à ce problème :
un lien (FILL->KILL) est introduit au niveau du serveur de trading MT5 entre les ordres Limit et les ordres Stop, ce qui donne ce qui suit :
- Avant d'exécuter un ordre Stop sur le marché, le serveur d'exécution supprime l'ordre Limit qui lui est associé.
- Lorsqu'un ordre Limit se déclenche, le serveur d'exécution supprime l'ordre stop qui lui est associé.
Tous les problèmes évoqués sont résolus très simplement - en introduisant des ordres de placement conditionnels sur le serveur. C'est d'ailleurs ce que font de nombreux courtiers qui travaillent selon le schéma d'échange classique. À cette fin, lors de la définition d'un ordre, nous devrions ajouter la possibilité de définir un ordre lié à annuler et à saisir. La logique est élémentaire : si l'ordre A est exécuté, alors les ordres B et C sont placés. Il en va de même pour l'annulation : si l'ordre A est exécuté, B et C sont annulés. Ou vice versa : l'ordre B est annulé si l'ordre A a atteint l'exécution. Et alors le problème du calcul de la position globale est résolu de façon élémentaire, ainsi que le problème de la mise en place et de l'annulation des TP et SL. En outre, il offre de nombreuses possibilités supplémentaires.
Z.U. Après avoir écrit, j'ai vu que getch l'avait déjà mentionné dans un post auparavant. Seulement, nous n'avons pas besoin de connecter uniquement les ordres de limite et d'arrêt. Si l'une d'entre elles peut être reliée, les possibilités sont beaucoup plus nombreuses.
Pour : getch
Решение данной проблемы видится так:
вводится связь (FILL->KILL) на уровне торгового сервера MT5 между Limit-ордерами и Stop-ордерами, которая дает следующее:
- перед тем, как сделать маркет-сиполнение Stop-ордера, удаляется Execution-сервером связанный с ним Limit-ордер.
- после срабатывания Limit-ордера, удаляется Execution-сервером связанный с ним Stop-ордер.
C'est difficile à faire car les commandes ont des tickets différents.
Vous devez saisir un champ supplémentaire sur le serveur et dans le terminal,
et MQ n'acceptera pas un mouvement aussi atypique.
TP et SL existent. Qu'importe s'il s'agit d'une position agrégée.
Comme l'a dit Integer, les arrêts sont un dernier recours :-)
Pour les Avals :
Ce sujet n'a rien à voir avec la façon dont cela peut être fait.
C'est possible.
Ce sujet concerne la fiabilité de l'exécution des ordres avec plusieurs EA et une position agrégée.
Ce n'est pas l'option la plus fiable.
À : getch
C'est difficile à faire car les commandes ont des tickets différents.
Vous devez saisir un champ supplémentaire sur le serveur et dans le terminal,
et MQ n'acceptera pas un mouvement aussi atypique.
TP et SL existent. Qu'importe s'il s'agit d'une position agrégée.
Comme l'a dit Integer, les arrêts sont un dernier recours :-)
MQ et SL sont les mêmes que getch))))) et c'est une étape 100% fiable et standard implémentée dans la plupart des logiciels de courtage.
Tous les problèmes évoqués sont résolus très simplement - en introduisant des ordres de placement conditionnels sur le serveur. C'est d'ailleurs ce que font de nombreux courtiers qui travaillent selon le schéma d'échange classique. À cette fin, lors de la définition d'un ordre, nous devrions ajouter la possibilité de définir un ordre lié à annuler et à saisir. La logique est élémentaire : si l'ordre A est exécuté, alors les ordres B et C sont placés. Il en va de même pour l'annulation : si l'ordre A est exécuté, B et C sont annulés. Ou vice versa : l'ordre B est annulé si l'ordre A a atteint l'exécution. Et alors le problème du calcul de la position globale est résolu de manière élémentaire, ainsi que le problème de la mise en place et de l'annulation des TP et SL. En outre, il offre de nombreuses possibilités supplémentaires.
Z.U. Après avoir écrit, j'ai vu que getch l'avait déjà mentionné dans un post auparavant. Seulement, il n'est pas nécessaire de connecter uniquement les ordres à cours limité et les ordres stop. Si vous pouvez en relier, les possibilités sont beaucoup plus grandes.
C'est ma faute, je ne l'ai pas compris. C'est une bonne idée. Des sortes de mini-scripts.
Mais le problème est que cela représente une charge encore plus importante pour le serveur que le stockage d'éléments non cumulatifs.
C'est ma faute, je ne l'ai pas compris. C'est une bonne idée. Une sorte de mini-scénario.
Mais le problème est que cela représente une charge encore plus importante pour le serveur que de stocker des éléments non cumulatifs.
L'utilisateur continuera donc à saisir ces demandes. En fait, tout est élémentaire et ne consomme aucune ressource. C'est une partie nécessaire de toute plateforme. Par exemple, QUIKa a http://www.quik.ru/about/features/conditional-orders/.
Alpha-Direct l'a http://www.a lfadirect.ru/help3_3/index.htm et d'autres plateformes de trading bourgeoises l'ont. Je ne me souviens pas d'un terminal qui ne l'ait pas.
J'ai écrit la même chose que getch)))) et c'est une étape 100% fiable et standard implémentée dans la plupart des logiciels de courtage.
D'autres possibilités sont offertes par les ordres OCO courants (les mini-scripts les plus primitifs sur le serveur de négociation). Le drapeau FILL->KILL sur le MT5 semble être suffisant. Certaines sociétés (à la StrategyRunner) ont choisi la voie du stockage des scripts et même des Expert Advisors sur leurs serveurs. Cette méthode a ses avantages (discutables) et ses inconvénients (discutables). MetaQuotes a pris un autre chemin.
D'autres possibilités sont offertes par les ordres OCO communs (mini-scripts primitifs sur le serveur commercial). Le drapeau FILL->KILL sur le MT5 semble être suffisant. Certaines sociétés (à la StrategyRunner) ont choisi la voie du stockage des scripts et même des Expert Advisors sur leurs serveurs. Cette méthode a ses avantages (discutables) et ses inconvénients (discutables). MetaQuotes a pris un autre chemin.
On ne sait pas encore très bien quelle voie ils ont choisie))))