Souhaits pour le MQL5 - page 28
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
peut-être cela a-t-il déjà été dit....
1) ajouter la capacité de compiler lorsqu'il est crypté et avec la possibilité de générer un numéro de série lié à un ID d'ordinateur (analogue à armandillo packer),
tout cela devrait être fait en interne dans le traducteur et non à partir de la source
2) Ajouter la possibilité de travailler de manière interactive avec des programmes externes ce qui permettrait de gérer le terminal à partir d'autres programmes, de se connecter/déconnecter au serveur, de vérifier la connexion au serveur, de demander des archives de devis, de passer des commandes... etc.
3) possibilité de passer des ordres indépendamment des ticks entrants
4) Prise en charge du travail simultané avec plusieurs DT/comptes
5) Relancer le débogage de la DLL
6) Ajouter au moins le support des structures, en général il serait souhaitable d'élargir les possibilités, afin qu'elles soient plus proches de c++.
Vous devez ajouter un lien exécutable vers l'aide fournie par le programme (par exemple, pour ouvrir une fenêtre avec le texte souhaité) et vers la page web.
Si l'utilisateur fait quelque chose d'incompréhensible, le programme lui dit : voici une consultation sur la situation, lisez-la correctement et ne faites plus de bêtises.
SK,
Par exemple, vous devriez définir TP=2 et SL=10 une fois et ensuite seulement acheter ou vendre, c'est-à-dire que le pipsing sera très pratique. En raison de cet inconvénient, j'ai récemment fait un Expert Advisor spécialement pour définir TP et SL avec les valeurs spécifiées après avoir cliqué sur Acheter ou Vendre.
Tant de souhaits pour tout ! 28 pages déjà !
J'aimerais que les développeurs me disent quels sont les souhaits déjà en cours de développement, ceux qui ne seront jamais mis en œuvre et ceux qui pourraient l'être.
Sinon, on ne sait pas si on doit souhaiter autre chose, on ne voit pas de retour.
Bien sûr, nous voulons aussi connaître le calendrier. Je comprends que prédire les conditions de lancement d'un logiciel n'est parfois pas plus facile que de prédire l'évolution des taux de change.
Du moins sous cette forme : "La version bêta de MT5 sera publiée au plus tôt à l'adresse .............". Est-il possible d'écrire une telle phrase ?
Sinon, il n'est pas clair s'il y a autre chose à souhaiter, aucun retour n'est visible.
A-t-on parlé de réaffecter Magic dans un ordre actif ? L'idée est simple : dans le cadre d'un trading multi-période, il sera possible de passer l'ordre à un cadre temporel supérieur lorsque la tendance est longue.
A-t-on parlé de réaffecter Magic dans un ordre actif ? L'idée est simple : dans le cadre d'un trading multi-période, il sera possible de passer l'ordre à un cadre temporel supérieur lorsqu'il existe une tendance longue.
En bref : j'utilise la même stratégie de trading pour 4 périodes, c'est-à-dire les principes d'entrée/sortie/traîne en utilisant un seul algorithme (un ensemble d'indicateurs et de types de signaux), mais les paramètres des indicateurs sont différents pour chaque période (cela signifie en fait 4 EA sur un seul graphique), division par Magic. Le résultat est le suivant : sur les échelles de temps inférieures, tout indique qu'il faut fermer les positions beaucoup plus tôt que la situation du marché ne le mérite vraiment (c'est-à-dire que toute oscillation du mauvais côté entraîne une prise de bénéfice), alors que sur les échelles de temps supérieures, la situation est très stable. Affecte la volatilité relative sur les indicateurs. Je pense que l'idée est claire - si des situations stables se produisent sur les échéances supérieures, les positions ouvertes sur les échéances inférieures ne devraient pas être fermées, mais en changeant de Magie, elles devraient être passées à la logique des échéances supérieures. L'application est en fait utilisée non seulement pour les délais, mais aussi pour le transfert vers d'autres logiques de traitement. Il me semble qu'il n'y aura pas de problèmes pour la société de courtage, car le billet reste, et le bénéfice peut être trouvé.
En bref : j'utilise une seule stratégie de trading pour 4 périodes, c'est-à-dire des principes d'entrée/sortie/traîne utilisant le même algorithme (un ensemble d'indicateurs et de types de signaux), mais les paramètres des indicateurs sont différents pour chaque période (en fait, ce sont 4 Expert Advisors sur un seul graphique), division par Magic. Le résultat est le suivant : sur les échelles de temps inférieures, tout indique qu'il faut fermer les positions beaucoup plus tôt que la situation du marché ne le mérite vraiment (c'est-à-dire que toute oscillation du mauvais côté entraîne une prise de bénéfice), alors que sur les échelles de temps supérieures, la situation est très stable. Affecte la volatilité relative des indicateurs. Je pense que l'idée est claire - si des situations stables se produisent sur les échéances supérieures, les positions ouvertes sur les échéances inférieures ne devraient pas être fermées, mais en changeant de Magie, elles devraient être passées à la logique des échéances supérieures. L'application est en fait utilisée non seulement pour les délais, mais aussi pour le transfert vers d'autres logiques de traitement. Il me semble qu'il n'y aura pas de problème pour DC, car le billet reste, et nous pourrions en tirer un certain profit.
Le sens est clair.
Mais je ne pense pas qu'il soit nécessaire de changer le langage et la technologie de communication entre le terminal et le serveur au nom de cette idée. Après tout, tout ce dont vous avez besoin peut être comptabilisé dans le programme du côté du terminal. D'ailleurs, l'idée même de changer le majik est une preuve éloquente du sous-développement de la stratégie, de ses critères. La magie (comme le montre clairement votre exemple) ne supporte pas et ne peut pas supporter un critère fixe pour fermer ou ouvrir un ordre. Tout simplement parce qu'un majik n'est pas lié au marché de quelque manière que ce soit.
À mon avis, c'est l'un des points clés du trading. Il se trouve que nous avions une magie dans nos mains, et nous l'avons attachée. En fait, nous devrions considérer la situation à chaque nouveau tick comme une nouvelle situation sans aucune préhistoire (historique des événements sur le compte de jeu, y compris l'heure et le prix d'ouverture des ordres de marché).
Et la magie est, bien que partiellement utile, mais à mon avis, pas un mécanisme très pratique pour suivre... qui sait quoi. Je pense que si un ordre pouvait être identifié de manière unique (lors de la réouverture et de la fermeture partielle), la magie perdrait toute signification.
Le point est clair.....
Je vais essayer de présenter quelques arguments, je vais commencer par la fin...
A mon avis, si nous acceptons l'ordre comme un objet, alors la magie du moment est une propriété totalement variable de cet objet du point de vue de la programmation, au même titre que les niveaux SL ou TP. Je me trompe peut-être mais actuellement il est impossible d'identifier clairement l'ordre dans MQL par rapport au code exécuté dans le terminal à toutes les étapes possibles de sa vie (à la réouverture et à la fermeture partielle) et la magie compense en grande partie cette situation. La magie ne doit pas être rattachée au marché - elle a simplement une autre application et n'a aucun sens, si ce n'est celui de sa signification.
Je ne suis pas d'accord avec vous pour considérer la situation du marché comme une situation sans histoire... Mais c'est mon opinion personnelle. Si l'ordre est rentable, nous devons regarder l'échelle de temps supérieure pour prendre une décision et soit attendre un petit repli et continuer à travailler avec l'ordre sur une échelle de temps supérieure, soit le fermer car il ne sera pas rentable.
Je ne vais pas débattre du bien-fondé et de la pauvreté de la stratégie - je suis tout à fait d'accord... Mais j'y travaille :-)
Changer le langage et le protocole d'échange entre le serveur et le terminal, eh bien, je ne sais pas ... Pour le moment, la valeur majuscule est déjà présente et est acceptée par le serveur lors de la commande. Je ne connais pas le format du protocole d'échange, mais je soupçonne qu'il s'agit d'une transmission par lots d'une structure de données via le transport, avec vérification ultérieure de la cohérence. Je pense qu'il n'est pas trop difficile d'ajouter un paramètre optionnel supplémentaire à la structure de données transmise par OrderModify. Je doute profondément que les développeurs aient pris la voie du protocole d'échange atomique et se soient ainsi enlisés dans le lourd processus de support des versions.
Mais en général, j'ai juste posé des questions sur les plans :-) Non, non.