Souhaits pour le MQL5 - page 29
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
Pour ce qui est de considérer la situation du marché comme histrionique, je ne suis pas d'accord avec vous... Mais c'est mon opinion personnelle. Dans le cas d'un ordre rentable, il est logique de regarder l'image supérieure pour décider s'il faut attendre un petit repli et continuer à travailler avec l'ordre sur une image supérieure ou simplement le fermer pour cause d'échec.
Je ne dis pas que vous ne devez pas tenir compte de l'historique du marché. En fait, c'est la seule chose qui peut et doit être prise en compte.
Je dis qu'il n'est pas logique (nuisible) de prendre en compte la date et le prix d'ouverture d'un ordre. En ce sens, la majik est un moyen d'entretenir les illusions :) Je ne veux pas me répéter, jetez un coup d'œil ici.
Et sur le fil, je ne pense pas que Majic fera l'affaire. Imaginez le nombre de programmeurs malheureux qu'il y a. Dans certains programmes, une demande de majik va certainement entrer dans une boucle et surcharger le serveur. Et si un seul de ces programmes est mis en circulation, ce sera la fin de toute cette technologie.
Et sur le fil, je ne pense pas qu'il y aura de majic. Imaginez combien de programmeurs misérables il y a. Dans certains programmes, une demande de majik va certainement entrer dans une boucle et charger le serveur. Si un seul de ces programmes est mis en circulation, toute la technologie sera ruinée.
Je pense m'être trompé : je ne suggérais pas de le demander séparément du serveur. J'ai suggéré de ne le remplacer que lorsque OrderModify est appelé.
Je vois ce que vous voulez dire..... le danger existe. Tout comme pour la réorganisation de SL et TP.
Je vois ce que vous voulez dire..... le danger existe. Tout comme pour le passage de SL et TP
C'est déjà un détail de ce qu'ils ne feront pas sans vous et moi :) Mais si c'était le cas, la demande ou la réponse serait également présumée - selon la façon dont on la regarde. Par exemple, un changement sur le SL du serveur à partir d'un PC connecté au compte répondra en affichant la nouvelle valeur du SL sur tous les PC connectés au compte.
Toi et moi sommes comme Dobczynski et Bobczynski :
Bobchinsky. ... "Eh !" Je dis à Peter Ivanovich...
Dobczynski. Non, Pyotr Ivanovich, j'ai dit : "э !"
Bobchinsky. D'abord tu l'as dit, et ensuite je l'ai dit. "Э ! - Peter Ivanovich et moi avons dit. - "Et pourquoi devrait-il s'asseoir ici, alors que la route pour lui
dans la province de Saratov ?"
Oui... Tout ce que l'utilisateur peut faire pour mettre le système à genoux, il le fera. Même sans revenir à la raison :-)
Malheureusement, en conséquence, de nombreux produits sont surchargés de contrôles et de revérifications, la protection de l'interface contre les "bêtises" et les actions accidentelles et imprévisibles des utilisateurs.
Récemment, j'ai dû communiquer avec un client qui interprétait le statut "Approuvé" d'un document officiel de manière quelque peu particulière. Le document est en quelque sorte approuvé et signé, mais tout ce qu'il contient peut être modifié sans qu'il soit nécessaire de le reconsidérer et de le réapprouver. Imaginons un exemple : vous envoyez un ordre de paiement à la banque, la banque l'exécute fidèlement, puis, après avoir corrigé le document original, vous vous présentez à la banque et faites une descente avec la mention "mauvaise exécution de l'ordre de paiement".
Malheureusement, en conséquence de cela, de nombreux produits sont surchargés de fonctionnalités de vérification et de revérification, de protection de l'interface contre les "fous" et les actions imprévisibles accidentelles des utilisateurs.
Oui, je suis bien conscient de cela. C'est pourquoi j'ai dû consacrer beaucoup de temps à rendre le programme infaillible, si bien que le travail s'est déjà étiré sur six mois. Et tout cela parce que l'utilisateur peut changer la couleur ou l'apparence de l'icône de contrôle et ensuite se plaindre.
Au fait, en ce qui concerne le sujet de ce fil. Il est nécessaire de disposer de propriétés d'objets ajustables par programme : interdire/autoriser les changements de couleur, de taille, de police, de mise en évidence, de suppression, etc.
Par exemple le même championnat, il est clair qu'un expert qui fonctionne bien n'a pas besoin d'une interface graphique.
Une grosse demande pour qu'il soit possible d'exécuter un EA (indicateur, script), non seulement à l'arrivée d'un nouveau tick, mais de différentes manières.
J'ai besoin
Peut-être comme ce démarrage à 3 fonctions
Start 0 {} // fonctionne par tic-tac
Start 1 {} // fonctionne par temps (sélectionner chaque seconde, minute, heure, etc.)
Start 2 {} // s'exécute sur un événement externe, par exemple lorsqu'un programme externe a terminé ses calculs et que les données ont été mises à jour dans le fichier de résultats de calcul de ce programme.
Merci d'avance.
Il peut également être utile de pouvoir organiser les indicateurs des utilisateurs par groupes dans des dossiers du système de fichiers. Ce n'est pas une bonne idée d'avoir un tas d'indicateurs dans un seul dossier :-)
Il serait également intéressant de pouvoir définir une échelle de prix fixe (pips/pixel), les limites de l'échelle étant automatiquement modifiées par des multiples d'une valeur donnée, par exemple 5 ou 10 pips.