La toile est cool ! - page 58
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
Je n'ai pas remarqué un tel besoin chez les commerçants. Nous ne parlons pas de rentabilité, nous parlons de toutes sortes de babioles dans un EA.
Et le bibelot le plus important d'une EA est sa rentabilité potentielle !
Et le bling le plus important d'un EA est son rendement potentiel !
Je vois, tout ce dont on peut parler... juste pour en parler.
Je vois, tout ce dont tu veux parler... juste pour parler.
Et parler et faire, si vous avez le cran de le faire.
Exact. Un EA classique - trois indicateurs pour générer un signal d'achat/vente, et quelques formules pour les stops. Quoi d'autre ? C'est triste.
Mieux - votre propre conseiller basé sur le Zigzag "normal" et certaines de ses caractéristiques.
Mieux - votre propre conseiller basé sur le Zigzag "normal" et certaines de ses caractéristiques.
Chacun son truc.
Surtout en allemand...
Que parlez-vous tous d'interfaces, alors que tout a été fait il y a longtemps et est disponible dans la bibliothèque standard comme analogue de MFC, y compris des exemples :
Il est trivial que vous discutiez sans connaître l'existence d'une bibliothèque permettant de construire des panneaux soignés et d'aspect professionnel. Ils sont en direct, glissent et déposent, minimisent, réagissent aux événements, etc.
Quelles autres structures graphiques lorsque l'entonnoir perd le taux de conversion dans la première étape "personne ne sait même qu'il existe une solution". Toute solution. Ils ne le lisent pas, ils ne savent pas et ne veulent pas savoir. Et il y a 13 mb de code source dans MQL5 dans la bibliothèque standard. Qui, sain d'esprit, irait y jeter un coup d'œil ?
Il vaut mieux discuter, donner des conseils et penser que l'on comprend le problème...
Renat, je travaille avec cette bibliothèque depuis deux ans maintenant. Le principal inconvénient est le caractère discret des contrôles et de leurs composants. Vous n'avez probablement pas eu l'occasion d'observer l'effet produit lorsque des éléments de formulaire sont glissés en boucle derrière le formulaire. C'est un joli spectacle, mais pas très productif. L'utilisation de l'approche MFC pour le traitement des événements est une bonne solution. J'ai déjà écrit dans des billets précédents que le squelette de la bibliothèque elle-même est bon, mais que nous devrons éventuellement nous éloigner des primitives discrètes et dessiner le résultat final (un formulaire avec des contrôles) sur un seul canevas et faire glisser et déposer un seul objet, plutôt qu'un tas d'objets primitifs changeant leur position dans une boucle.
Bien sûr, on peut dire : il y a une bibliothèque, de quoi d'autre avez-vous besoin ? Et se calmer sur ça, ou juste traiter tout de cette façon. C'est votre droit.
Mais en ce qui concerne la visualisation et l'interface graphique, personne ne vous demande quoi que ce soit, c'est juste une discussion entre utilisateurs intéressés.
Pourquoi discutez-vous tous d'interfaces, alors que tout a été fait depuis longtemps et est disponible dans la bibliothèque standard comme analogue du MFC, y compris des exemples ?
Il est trivial que vous discutiez sans connaître l'existence d'une bibliothèque permettant de construire des panneaux soignés et d'aspect professionnel. Ils sont en direct, glissent et déposent, minimisent, réagissent aux événements, etc.
J'ai oublié de mentionner que les graphiques sont glitchy, sous-écrits, et non réparables pendant des années.
Il y a suffisamment de sujets identiques sur les bogues de la bibliothèque graphique standard, mais ils ne vous intéressent pas.
D'autre part, le début est posé, les analogues sont écrits, et tous ceux qui veulent peuvent vraiment finir le fichier ce qui est (s'ils veulent apprendre 13 Mb de très controversé dans certains endroits le code source).
Mais le retour d'information fait souvent défaut, même sur les rapports de bogues, il n'y a pas toujours de réponses...
Vous avez oublié de mentionner que les graphismes sont glitchy, sous-développés et non réparables depuis des années.
Je ne pense pas que les performances graphiques soient nécessaires pour travailler, en général il est réaliste de faire la plupart des désirs graphiques du SB en quelques jours.
Je ne peux même pas faire de commentaire à ce sujet car la solution est trop horrible pour être utilisée dans le test ! - je ne veux même pas faire de commentaires à ce sujet
Je ne pense pas que vous ayez besoin de beaucoup de performances pour les graphiques, en général, il est réaliste de réaliser la plupart de vos aspirations graphiques en quelques jours.
Mais le fait que le comportement des graphiques dans le testeur soit différent - c'est un vrai problème ! - Je ne veux même pas faire de commentaires à ce sujet.
Il ne s'agit pas de performances, mais de bugs dans les performances.