Questions d'un "mannequin - page 12
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
VEUILLEZ ME CONSEILLER SUR LE TERMINAL DE TÉLÉPHONIE MOBILE.
QUAND ET QUAND UN SUPPORT POUR LES INDICATEURS UTILISATEURS (NON STANDARD) OU UNE CONSULTATION SUR mql4 OU mql5 SERONT REALISES ?????????????????????????????
SUR QUELLES PLATEFORMES (ANDROID PAR EXEMPLE) CELA SERA MIS EN ŒUVRE ????????????????? ET COMBIEN DE TEMPS ?????????????
en attente d'une RÉPONSE, merci pour l'info.
Interesting:
Je ne suis pas d'accord avec cette conclusion. OCO == "l'un annule l'autre". Dans MT5, il n'existe pas d'ordre qui annule l'autre. Je le regrette depuis un an. Lesfonctions telles que SL et TP permettent réellement de fermer une position ouverte, mais la question de l'"annulation" des ordres en attente n'a rien à voir avec cela.
Ils le font, mais ces ordres sont mis en œuvre sur le serveur. Et ce sont les seuls à être réellement intégrés dans le schéma OCO jusqu'à présent (et il ne nous viendrait pas à l'idée d'implémenter des ordres "If Done" directement dans le terminal et sur le serveur).
Lorsque l'on ouvre une position et que l'on fixe le TP et le SL dans MT5, on utilise essentiellement le même formulaire (mais le résultat ici est une position + 2 ordres d'annulation).
Après votre message, j'ai déjà commenté cette situation en tenant compte des SL et TP annulés de manière interchangeable. Toutefois, je voudrais ajouter ce qui suit.
Si l'on avait dit aux auteurs des ordres OCO qu'au 21ème siècle leur invention ne serait appliquée qu'aux niveaux SL et TP, ils auraient été très surpris de voir une telle limitation du domaine d'application de leur invention :) .En fait, tout est à l'envers : tous les documents que vous lisez font référence à la même chose : les ordres CCA sont des ordres interchangeables dont les types sont désormais spécifiés dans l'énumération ENUM_ORDER_TYPE de MQL5. Je n'ai jamais rencontré de mention du lien entre les ordres CCA et les niveaux SL-TP. Ainsi, le mécanisme d'exécution peut être le même mais ce sont les commandes ENUM_ORDER_TYPE que le client exécute mais pas les niveaux SL-TP (selon MQ).
Ainsi, lorsque j'écris sur les ordres en attente, je veux parler des ordres de la liste ENUM_ORDER_TYPE et non des ordres "dérivés" basés sur les niveaux SL-TP.
______________
* Le "dérivé" car chacun des ordres OCO peut avoir des niveaux SL-TP différents.
Messieurs, la base de la compréhension réside dans la simplicité de la plate-forme. La simplicité pour 99 % des utilisateurs et un rejet conscient des complications que le pourcentage restant d'utilisateurs peut comprendre.
Posez-vous la question suivante : "Que faudrait-il faire pour attirer X millions d'utilisateurs sur les marchés financiers ? Avec suffisamment d'expérience, la réponse sera proche de "faire un système simple, en supprimant la complexité et en réunissant les traders dans un seul écosystème".
Au lieu d'empiler les paramètres d'ordre de l'OCO (le panneau n'est vraiment pas pour l'esprit moyen), nous avons proposé un schéma de gestion des ordres très simple et direct avec SL/TP intégré. La grande majorité des ordres OCO ne sont que des SL/TP pour les positions actuelles. En plaçant SL/TP à l'intérieur, nous avons minimisé le nombre d'ordres supplémentaires et grandement simplifié la gestion des transactions.
ps : le problème du système de commande est clos
ps : le problème du système de commande est clos
ps : le problème du système de commande est clos.
Il est dommage qu'il ne soit pas possible de créer des SLs/TPs normaux (fiables) pour des transactions individuelles (et non des positions totales).
Cela réduit immédiatement la possibilité de négocier (de manière fiable) plusieurs stratégies sur le même instrument/compte.
Hali-vor ne devrait pas être repris, je me souviens de l'avis des développeurs (un instrument = une position = un SL et un TP)...
À quel type (long ou ulong) ORDER_MAGIC appartient-il réellement ?
ENUM_ORDER_PROPERTY_INTEGER
ORDER_MAGIC
Identifiant du conseiller expert qui a passé l'ordre (destiné à ce que chaque expert place son propre numéro unique)
long
À quel type (long ou ulong) ORDER_MAGIC appartient-il réellement ?
ENUM_ORDER_PROPERTY_INTEGER
ORDER_MAGIC
Identifiant du conseiller expert qui a passé l'ordre (destiné à ce que chaque expert place son propre numéro unique)
long
Je pense que le résultat doit être converti au type déclaré dans le code (il peut y avoir une erreur dans la documentation).
Si nous parlons de MqlTradeRequest, dans ce cas, c'est très probablement (ulong).
A mon avis, le résultat devrait être converti au type déclaré dans le code (il peut y avoir une coquille dans la documentation).
Quant à MqlTradeRequest, dans ce cas, c'est très probablement (ulong), mais probablement long fera l'affaire sans problèmes.
En général, la réponse n'est pas sur le fond. La question était très claire : "à quel type (long ou ulong)ORDER_MAGIC appartient-il réellement ?".
Essayons d'être plus substantiels :
1. ces deux types peuvent être déclarés sans transformation.
2. Si vous n'utilisez que des valeurs positives de magik, il est plus rentable de spécifier sa valeur comme ulong (car il y a une gamme de valeurs possibles de 0 à 18 446 744 073 709 551 615).
3. D'autre part, la classe CExpert de la bibliothèque standard applique la valeur longue dans l'initialisation (ce qui vous permet de spécifier des valeurs négatives, mais décale la plage des valeurs possibles). Ainsi, lors de l'initialisation de cette classe, la valeur de magik peut déjà être de -9 223 372 036 854 775 808 à 9 223 372 036 854 775 808.
Cette déclaration doit être vérifiée.
4. Mais la classe CTrade (de la même bibliothèque standard) a déjà une valeur ulong comme elle devrait l'être en fonction de la structure de la requête.
Tirons quelques conclusions préliminaires :
a) Le travail avec magik dans les classes CExpert et CTrade n'est pas cohérent, puisque dans le premier cas long est spécifié, alors que dans l'autre ulong;
b) Les classes en question ont été développées par des personnes différentes, ou l'ensemble et la structure des paramètres de certaines fonctions de CExpert ont été écrits en pensant à CTrade (qui peut ou non avoir existé dans le passé).
c) Le travail des experts associés à l'élaboration et à la documentation de la bibliothèque standard n'est pas totalement cohérent (bien que l'on ait généralement constaté une assez bonne étude des questions clés).
d) Si je comprends bien, l'interaction de ces deux classes limite la valeur du magicien à un intervalle de 0 à 9 223 372 036 854 775 808. Cette déclaration doit être vérifiée.
5. La structure MqlTradeRequest a le type ulong pour fonctionner avec magik. Tout est parfaitement cohérent avec la classe CTrade, c'est pourquoi il est plus logique de spécifier la plage des valeurs possibles du magicien de 0 à 18 446 744 073 709 551 615 si nous utilisons uniquement cette classe. Cette déclaration doit êtrevérifiée.
PS
Je pense que les développeurs ont intentionnellement "bridé" les valeurs possibles d'un magicien dans la fourchette de 0 à 9 223 372 036 854 775 808.
Les développeurs semblent avoir délibérément "tassé" les valeurs possibles d'un magik dans une fourchette de 0 à 9 223 372 036 854 775 808.
En fait, il y a jusqu'à 8 octets d'informations données à la magie, qui peuvent être interprétées comme vous le souhaitez. Il peut être de type date, double, 4 short, 8 char, ou 64 bits bit par bit.
Avec les quatre, 4 octets de magie suffisaient pour coder n'importe quoi, mais maintenant nous en avons 8. Il suffit d'en avoir la volonté.