La toile est cool ! - page 55
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
Si vous vous souvenez de Borland, l'interface graphique était assemblée dans un éditeur visuel, la disposition des contrôles était placée dans une barre d'outils, et ensuite vous écriviez les gestionnaires.
Si ME disposait d'une telle fonctionnalité graphique pour construire des mises en page en mode visuel, cela rendrait la construction d'applications graphiques beaucoup plus facile.
La majorité des programmeurs modernes, qui ont étudié la construction d'interfaces graphiques, se sont habitués (c'est ce qu'on leur a appris) à l'éditeur visuel d'interface graphique,
Et construire la mise en page d'une application graphique sur du code pur de style C ne les intéresse guère. Puisqu'il s'agit déjà d'un style C pur et dur.
Nous avons besoin d'un éditeur visuel pour construire une application graphique, et alors les gens seront impatients de l'apprendre, et ceux qui ont travaillé dans VS ou RadStudio, ils maîtriseront même rapidement l'éditeur visuel.
Il existait déjà un prototype d'un tel éditeur visuel dans MQL. Cependant, les gens s'y sont opposés avec véhémence. Ils ont dit que ce n'était pas nécessaire dans le commerce.
En général, ils ont démoralisé du mieux qu'ils ont pu. Par conséquent, je ne sais pas ce dont la communauté a vraiment besoin.
Je soutiens pleinement le besoin d'avoir la possibilité de collecter...
Mais savoir si c'est nécessaire ou non est une autre question.
Je me demande si les développeurs eux-mêmes considèrent le terminal comme un outil de trading ou un outil de programmation ?
Je peux me tromper à ce stade, mais j'ai toujours pensé que ME était conçu pour mettre en œuvre exactement la fonctionnalité dont l'utilisateur a besoin pour négocier. Exactement le commerce !
Mais aujourd'hui, la profondeur de la programmation dans ME a atteint des domaines où il faut vraiment être capable de "construire" des dés et avoir une compréhension très sérieuse de la programmation.....
Et à quoi cela mène-t-il à la fin ? Il en résulte que les outils de trading avancés ne sont accessibles qu'aux programmeurs expérimentés !
Autrement dit, si vous n'êtes pas un programmeur, vous n'avez rien à faire dans le commerce... Mais c'est absurde.
ME n'est qu'un assistant pour combler les fonctionnalités manquantes, qui auraient été plus correctement intégrées dans le terminal lui-même (différents assistants).
En fait, ME est en train de devenir un nouvel environnement de développement, qui exige de plus en plus de connaissances de la part des utilisateurs.
Sur la base de cette conclusion, les outils de visualisation sont nécessaires, mais leur utilisation doit être accessible aux utilisateurs qui n'ont pas de connaissances approfondies en programmation.
C'est seulement dans ce cas qu'ils seront demandés.
Ce n'est que mon opinion et je ne l'impose à personne.
Si l'on considère la classe CCanvas, il y a environ 20 fonctions de dessin de primitives graphiques. Supposons qu'un utilisateur les connaisse tous et qu'il connaisse les règles et la syntaxe de la POO. Cependant, c'est trop peu jusqu'à la visualisation la plus simple de ses données. Sans oublier la création de la commande la plus simple - un bouton. En d'autres termes, il est relativement facile de dessiner des primitives sur le canevas, mais l'utilisation de ces primitives pour créer une visualisation ou une interface graphique est beaucoup plus difficile. Et vous ne pouvez pas faire ici sans connaissances - vous ne pouvez pas faire ici sans le talent du développeur. Mais combien de personnes l'ont ? C'est le principal problème.
Afin d'utiliser le potentiel de la classe Kanvas, vous devez être capable de combiner des primitives graphiques en objets plus complexes (contrôles), de lier leur fonctionnement au modèle événementiel, d'écrire les relations avec des fonctions... Ou encore, convertir des données numériques en différentes courbes graphiques... Ce travail est destiné aux utilisateurs talentueux et très travailleurs. En fait, pas les utilisateurs, mais les développeurs.
Il existait déjà un prototype d'un tel éditeur visuel dans MQL. Cependant, les gens s'y sont opposés avec véhémence. Ils ont dit que ce n'était pas nécessaire dans le commerce.
En général, ils ont démoralisé du mieux qu'ils ont pu. Par conséquent, je ne sais pas ce dont la communauté a vraiment besoin.
Wow, donc il y a un prototype.
Alors peut-être que les développeurs devraient reconsidérer les vues superficielles de la communauté ? Et relancer le projet de développement d'un mode visuel.
C'est un peu bizarre, bien sûr, de démoraliser une fonction essentiellement très recherchée.
Il existe aujourd'hui très peu d'endroits où l'on enseigne comment construire une interface graphique dans le style C, si tant est qu'on l'enseigne encore.
Aujourd'hui, tout le monde apprend à travailler dans un IDE en mode visuel, et comme MT5 a dépassé depuis longtemps le stade de la simple plateforme de négociation,
, le mode visuel de construction d'applications graphiques sera très demandé.
Honnêtement, je suis choqué que les développeurs aient écouté les personnes à courte vue qui étaient contre.
Si nous considérons la classe CCanvas, il y a environ 20 fonctions pour dessiner des primitives graphiques. Supposons que l'utilisateur les connaisse tous et qu'il connaisse les règles et la syntaxe de la POO. Cependant, jusqu'à la visualisation la plus simple de ses données - c'est trop peu. Sans oublier la création de la commande la plus simple - un bouton. En d'autres termes, il est relativement facile de dessiner des primitives sur le canevas, mais l'utilisation de ces primitives pour créer une visualisation ou une interface graphique est beaucoup plus difficile. Et vous ne pouvez pas faire ici sans connaissance - vous ne pouvez pas faire ici sans le talent du développeur. Mais combien de personnes l'ont ? C'est le principal problème.
Afin d'utiliser le potentiel de la classe Kanvas, vous devez être capable de combiner des primitives graphiques en objets plus complexes (contrôles), de lier leur fonctionnement au modèle événementiel, d'écrire les relations avec des fonctions... Ou encore, convertir des données numériques en différentes courbes graphiques... Ce travail est destiné aux utilisateurs talentueux et très travailleurs. En fait, pas les utilisateurs, mais les développeurs.
Peter, tu dis les bons mots !
Je préconise donc la création de telles bibliothèques qui seraient intuitivement compréhensibles pour les programmeurs qui ne sont pas familiers avec la POO également.
Et cela ne s'applique pas seulement aux interfaces graphiques.
Dans la bibliothèque standard et dans celle d'Anatoly, il faudrait beaucoup d'efforts pour construire un formulaire simple ! Pour de vrai ! Un pas à droite ou à gauche des exemples et c'est tout, rien ne fonctionne, il faut comprendre tous les détails.
Dans tous les langages, bien sûr, l'interface graphique est également construite sur des bibliothèques, mais il y a un MAIS important ! Il existe un ensemble initial de contrôles qui, au niveau du noyau de la bibliothèque, sont complètement "liés" les uns aux autres, tous les gestionnaires d'événements de base sont "câblés", il ne reste plus qu'à s'y abonner si l'on veut modifier le comportement ou la présentation.
En fait, l'architecture de la bibliothèque standard est très bien pensée et pourrait servir de base à une bibliothèque plus avancée.
Wah, donc il y a un prototype disponible.
Alors peut-être que les développeurs devraient reconsidérer les vues superficielles de la communauté ? Et relancer le projet de développement d'un mode visuel.
Il est étrange, bien sûr, qu'ils aient démoralisé une fonction essentiellement très recherchée.
Après tout, rares sont les établissements qui enseignent aujourd'hui comment construire une interface graphique dans le style C, si tant est que cela soit encore enseigné.
Ils apprennent maintenant à travailler en IDE avec le mode visuel, et depuis que MT5 n'est plus seulement une plateforme de trading,
alors le mode visuel de construction d'applications graphiques serait très demandé.
Pour être honnête, je suis choqué que les développeurs aient écouté les personnes à courte vue qui étaient contre.
Il y a quelques autres facteurs surprenants : les indicateurs sont visuels à 100%, les EA à 80% et les scripts à 20%. Quel que soit le nom qu'on lui donne, tout est visuel et la compréhension de ce phénomène se trouve à la surface. Cependant, il y a un développement sur l'intégration avec d'autres environnements de développement, et ce qui est à la surface....
Apparemment, tous les autres utilisateurs de terminaux demandent python et sql.
Roman, Peter, Nikolaï... les développeurs de terminaux ont leur propre vision, ils sont les auteurs et les propriétaires du produit logiciel. Je suppose que le développement de la fonctionnalité ME et du terminal dans son ensemble est basé sur des études de marché.
Mais personne ne nous empêche de parler :)
Il existe quelques autres facteurs surprenants : les indicateurs sont visuels à 100%, les EA à 80% et les scripts à 20%. Quel que soit le nom qu'on lui donne, tout est visuel et la compréhension de ce phénomène se trouve à la surface. Cependant, il y a un développement sur l'intégration avec d'autres environnements de développement, et ce qui est à la surface....
Apparemment, tous les autres utilisateurs de terminaux demandent python et sql.
Roman, Peter, Nikolay... Les développeurs du terminal ont leur propre vision, ils sont les auteurs et les propriétaires du produit logiciel. Je pense que le développement de la fonctionnalité ME et du terminal en général est basé sur une étude de marché.
Mais personne ne nous empêche de parler :)
C'est vrai.
Mon opinion est la suivante : l'interface visuelle des EA permettra d'accumuler les stratégies dans une seule application, ce qui aura un effet négatif sur les ventes sur le marché. Si tout le monde peut facilement créer des conseillers experts avec un ensemble dynamique de stratégies (l'interface graphique le permet), leur rotation actuelle sur le marché diminuera, ce qui affectera les ventes. Les conseillers experts qui intègrent et modifient les stratégies en interne passeront au premier plan et élimineront les clones qui ne diffèrent que par des paramètres ou quelques conditions. Est-ce que ce sera bon pour Marketplace ? Je ne sais pas. Mais le niveau des conseillers experts va s'élever et il deviendra beaucoup plus intéressant de les examiner dans la vitrine.
La plupart des utilisateurs souhaitent peut-être que CCanvas, CGrafic et CCanvas3D soient des applications qui produisent les visualisations requises, plutôt que des classes qui nécessitent une connaissance des principes et de la syntaxe de la POO. Et pas seulement pour savoir, mais essentiellement pour construire leur propre système de visualisation, comme le fait Nicholas.
Quel est le principe de l'oop que vous devez connaître ? Mettre un point et choisir une méthode dans la liste ?
Une question complémentaire : combien et quelles sont les fonctions MQL "les plus puissantes" et "les plus simples" ?
est suffisant pour écrire un conseiller expert entièrement fonctionnel et potentiellement le plus rentable pour n'importe quel type d'entreprise.
des principales paires de devises du monde ?
Et quelle fonction R ou Python, dont tout le monde ici a perdu la tête, suffit pour écrire... ? Et regardez, le tabouret sur lequel vous êtes assis - est-il adapté à ce... ?
Eh bien, si vous vous souvenez de Borland, l'interface graphique était assemblée dans un éditeur visuel, vous mettiez la disposition des contrôles sur le panneau et ensuite vous écriviez les gestionnaires.
Si ME disposait d'une telle capacité à construire des mises en page visuellement, cela simplifierait grandement la construction d'applications graphiques.
La majorité des programmeurs modernes, qui ont étudié la construction d'interfaces graphiques, se sont habitués (c'est ce qu'on leur a appris) à l'éditeur visuel d'interface graphique,
Et construire la mise en page d'une application graphique sur du code pur de style C ne les intéresse guère. Puisqu'il s'agit déjà d'un style C pur et dur.
Nous avons besoin d'un éditeur visuel pour construire une application graphique, et alors les gens seront impatients de l'apprendre, et ceux qui ont travaillé dans VS ou RadStudio, ils maîtriseront même rapidement l'éditeur visuel.
Pourquoi en a-t-on besoin ici ?
C'est vrai.
Mon opinion est la suivante : l'interface visuelle des EA permettra d'accumuler les stratégies dans une seule application, ce qui aura un impact négatif sur les ventes du marché. Si tout le monde peut facilement créer des conseillers experts avec un ensemble dynamique de stratégies (l'interface graphique le permet), leur rotation actuelle sur le marché diminuera, ce qui affectera les ventes. Les conseillers experts qui intègrent et modifient les stratégies en interne passeront au premier plan et élimineront les clones qui ne diffèrent que par des paramètres ou quelques conditions. Est-ce que ce sera bon pour Marketplace ? Je ne sais pas. Mais le niveau des EA va augmenter et il deviendra beaucoup plus intéressant de les regarder en vitrine.
C'est un problème tout à fait farfelu.
L'interface visuelle pour la collecte de stratégies est inutile, si vous avez besoin de dés, allez sur tslab.
Et j'ai vu des programmes pour générer du code mql qui rassemblent des stratégies avec des cubes en mode visuel.
Nous n'avons pas besoin du mode visuel pour développer des stratégies de trading et des indicateurs, il est vraiment inutile.
Mais pour les applications graphiques modulaires, le mode visuel, comme vous l'avez montré dans le gif, serait utile.