La grande et terrible MT4 pour toujours (ou comment organiser une transition) - page 30
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
C'est une chose étrange à faire sur les Forts. Voici la partie principale de la fermeture de la position.
Voici un extrait du journal du conseiller expert, c'est-à-dire qu'il est arrivé à la section où le ticket de transaction est nul après 20 itérations de la vérification de ResultDeal() :
JL 0 10:08:04.462 e-MultiPattern-0.15 (RTS-9.21,M5) cStoploss::sortSL12 Дистанция контртренд=0 BID=172690.0, закроем Short
JM 0 10:08:06.695 e-MultiPattern-0.15 (RTS-9.21,M5) ** 333-cMyTrade::ClosePosition. После закрытия позиции № сделки=0, Order=16868286 state=ORDER_STATE_FILLED
Voici un extrait du journal du terminal :
IG 0 10:08:04.465 Trades '733618' : échange d'achat 2 RTS-9.21 au marché
KN 0 10:08:04.480 Transactions '733618' : achat en bourse accepté 2 RTS-9.21 au marché
OQ 0 10:08:04.481 Transactions '733618' : achat en bourse 2 RTS-9.21 au marché placé pour exécution
FG 0 10:08:04.517 Trades '733618' : ordre #16868286 buy 2 / 2 RTS-9.21 au marché fait en 52.326 ms
JN 0 10:08:04.517 Trades '733618' : deal #3413752 buy 2 RTS-9.21 at 172780 done (based on order #16868286)
Veuillez indiquer qui a une bonne connaissance de la logique commerciale de MT5. Dans le journal du terminal, la commande et la création de la transaction ont eu lieu en un instant - 04.517 secondes.
Mais l'EA dans la boucle while n'a jamais vu de ticket de transaction et s'est arrêté après 20 itérations à 06,695 secondes. Pourquoi la structure a-t-elle un ticket de commande mais pas de ticket de transaction ?
Comment est-il garanti d'obtenir un ticket d'échange, surtout si vous utilisez une fermeture partielle ?
On ne peut pas l'expliquer facilement car il y a beaucoup de pièges. Rédiger une solution qui permet aux utilisateurs de travailler sans problème. Mais l'analyse de l'implémentation interne est réservée aux connaisseurs.
Et très sérieusement... ?
Le fil "Humour" ici
La compatibilité ascendante est l'une des exigences de base pour les logiciels. Le code d'une version précédente doit être perçu de manière adéquate par la version suivante. Sinon, le développeur jette simplement le développement précédent et en introduit un nouveau. Le chemin vers nulle part.
Je suis tout à fait d'accord pour dire qu'il est nécessaire (avant tout, pour les développeurs) de compiler le code MQL4 en code MQL5.
Faites un bon testeur pour mt4 et dans quelques années mt5 sera oublié par tout le monde.
Baskakov, et la fille utilise MT5, l'infâme...
Si ResultDeal est égal à zéro, il le sera toujours après un million d'itérations dans la boucle, car c'est un paramètre invariant.
Parce que l'ordre de marché placé est le résultat de OrderSend.
Ce n'est pas très clair. Dans l'aide de la structure de MqlTradeResult , il est indiqué que
Si la clôture a renvoyé un ticket d'ordre mais qu'il n'y a pas de ticket d'ordre, ce type d'opération est-il TRADE_ACTION_PENDING ?
Ou TRADE_ACTION_DEAL et le ticket de transaction peut être "en retard" et ne pas être inclus dans la structure ?
C'est-à-dire qu'il est préférable de rechercher une affaire par ordre à travers les fonctions HistorySelect ?
Et aussi, je suis désolé, c'est un point sensible. Pour les développeurs : arrêtez de gaspiller des dépenses folles et injustifiées pour la maintenance de MT4, la moitié de vos professionnels de haut niveau s'en occupe déjà.
Construire le compilateur MQL4-MQL5 une fois et se concentrer sur les choses importantes. Obtenez une première place stable dans la version finale parmi vos concurrents.
Ce n'est pas très clair. Dans l'aide pour la structure MqlTradeResult il est écrit
Si la clôture renvoie un ticket d'ordre, mais qu'il n'y a pas de ticket de transaction - s'agit-il d'une transaction de type TRADE_ACTION_PENDING ?
Ou TRADE_ACTION_DEAL et le ticket de transaction peut être "en retard" et ne pas être inclus dans la structure ?
En d'autres termes, est-il préférable de rechercher l'affaire par ordre à l'aide des fonctions HistorySelect ?
Bien que la méthode PositionClose(Symbol) de SB attribue le type de transaction TRADE_ACTION_DEAL.
Il s'avère qu'il devrait y avoir un ticket commercial, mais qu'il est souvent absent.