Mon approche. Le noyau est le moteur. - page 26
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
Les constructeurs d'interface graphique sont conçus pour une bibliothèque graphique spécifique. S'il existait un constructeur d'interface graphique pour MQL, il serait ici.
J'ai vu un article quelque part, dans Hubre, semble-t-il, comme "créer un constructeur d'interface graphique pour Python", alors j'ai pensé que peut-être quelqu'un avait vu une interface graphique multiplateforme où je pourrais ajouter mon propre code.
Mais si je veux écrire un constructeur à partir de zéro, je préfère utiliser MQL.
1. je ne l'ai jamais développé en Sharp, cela ne m'intéressait pas, mais il y a environ 5 ans, j'ai utilisé Delphi pour connecter une .dll avec des boutons et des formulaires et cela a fonctionné sans problème, d'ailleurs j'ai écrit tout le projet en Delphi en une journée, j'ai passé une demi-journée à essayer de trouver la raison pour laquelle les formulaires standard ne fonctionnaient pas, mais quand je l'ai connecté en appelant les fenêtres du système, tout fonctionnait correctement, mais MT4 était très lent à l'époque, il traîne maintenant il vole.
je n'ai aucun problème pour connecter .dll, synchroniser avec les mutex standards - démarrer un thread pour se connecter au terminal et c'est tout, ensuite tout se passe tout seul - séparément un formulaire dans .dll, séparément MT personne n'attend personne
SZS : veuillez noter que Delphi n'est pas très pratique pour créer une .dll, mais j'ai utilisé ce que j'avais sous la main (ce sur quoi j'étais assis à l'époque))))))
2. pour ce qui est de l'essentiel, je ne comprends pas pourquoi ils ne peuvent pas utiliser les classes standard de la boîte à outils MT, ce serait cool d'unifier le processus de création graphique, peut-être que ce serait une inclusion universelle où l'on pourrait commenter les boutons/dialogues inutiles, etc.
1. c'est une façon très, très amateur d'aborder le problème (sans vouloir vous offenser). Un projet qui se fait en un jour n'est pas un projet. C'est une petite tâche.
Imaginez que vous créez une application composée de 10 fenêtres, parmi lesquelles se trouvent de grands tableaux de données, des fenêtres de paramétrage et des boîtes de dialogue. Vous les dessinez dans Delphi. Ensuite, vous créez une DLL. Ensuite, vous le connectez à votre projet MT.
Votre application MT doit être connectée à l'interface graphique Delphi via la mémoire partagée. Connectez les fonctions aux contrôles, et les données aux cellules du tableau. Vous devez organiser l'interaction complexe des deux parties de l'application et y réfléchir correctement.
Vous avez besoin du fonctionnement synchrone et de l'échange de valeurs de paramètres entre les deux parties - GUI et application MT.
Encore une fois : si votre application est grande et sérieuse (tableaux, fenêtres de paramétrage, boîtes de dialogue, listes anciennes, etc...) créer un travail unique, cohérent et efficace de deux parties via DLL est une tâche TRÈS sérieuse. Je l'ai fait et je sais de quoi je parle.
Et vous parlez d'une petite tâche qui peut être réalisée en un jour. Ce n'est pas grave.
Il y a longtemps que vous pouvez utiliser la bibliothèque standard. Mais la question porte sur l'effort requis et le résultat que vous obtiendrez. Qu'est-ce que c'est ? Je sais qu'Anatoly a utilisé la bibliothèque standard comme tremplin pour créer sa propre bibliothèque. Mais pourquoi l'a-t-il fait, si la bibliothèque standard fonctionne aussi ? La réponse est simple : il a implémenté tout ce qui était de meilleure qualité et est allé au-delà de la bibliothèque standard. Mais la diffusion massive ne peut se faire qu'en réduisant la difficulté d'utilisation. Plus l'utilisation est facile, plus il y aura d'utilisateurs (avec une augmentation de la qualité bien sûr).
1. Il s'agit d'une façon très, très amateur d'aborder le problème (sans vouloir vous offenser). Un projet qui se fait en un jour n'est pas un projet. C'est une petite tâche.
Imaginez que vous créez une application composée de 10 fenêtres, parmi lesquelles se trouvent de grands tableaux de données, des fenêtres de paramétrage et des boîtes de dialogue. Vous les dessinez dans Delphi. Ensuite, vous créez une DLL. Ensuite, vous le connectez à votre projet MT.
Votre application MT doit être connectée à l'interface graphique Delphi via la mémoire partagée. Connectez les fonctions aux contrôles, et les données aux cellules du tableau. Vous devez organiser l'interaction complexe des deux parties de l'application et y réfléchir correctement.
Vous avez besoin du fonctionnement synchrone et de l'échange de valeurs de paramètres entre les deux parties - GUI et application MT.
Encore une fois : si votre application est grande et sérieuse (tableaux, fenêtres de paramétrage, boîtes de dialogue, listes anciennes, etc...) créer un travail unique, cohérent et efficace de deux parties via DLL est une tâche TRÈS sérieuse. Je l'ai fait et je sais de quoi je parle.
Et vous parlez d'une petite tâche qui peut être réalisée en un jour. Ce n'est pas sérieux.
Quels sont vos griefs ? Vous ne comprenez pas que l'échange de données entre MT et .dll est vieux comme le monde.
Je faisais un .dll parce qu'il n'y avait pas de graphiques décents dans MT, je voulais des boutons et un panneau.
des tables ? - bien dessiner des tableaux, des contrôles ? - dessiner.... Il est impossible de séparer la tâche. Dans le même Delphi, il existe de nombreux composants prêts à l'emploi, tant pour créer des bases de données que pour travailler avec elles.
I.e. de MT vous avez seulement besoin des données elles-mêmes, et le reste fera un programme tiers, vous pouvez prendre votre mot pour elle, mais dans le même Delphi pour écrire le travail avec la base de données, avec la sortie dans les tableaux, les graphiques, etc. travail pour un jour ;)
Qu'est-ce qu'une donnée en MT ? = il s'agit juste d'un tick et d'une barre, et il n'y a aucun intérêt à "courir" à travers un .dll - il suffit de tout mettre dans un fichier une fois et de travailler avec le fichier dans un programme tiers.
SZS : quelqu'un a écrit récemment sur le forum que les entreprises informatiques modernes apprécient les employés qui ne comprennent pas complètement le code dans lequel ils travaillent, mais ceux qui, dès que possible, peuvent accomplir un grand volume de tâches, c'est-à-dire qu'ils doivent être capables d'intégrer le travail d'autres personnes dans leur tâche, et non pas construire à chaque fois tout à partir de zéro ! Je ne connais pas votre profession principale, je n'ai jamais travaillé comme programmeur, mais je travaille constamment dans des domaines connexes, pendant longtemps engagé dans la maintenance des contrôleurs industriels, ACS et ACS, et a dû faire ajouter des solutions de programme et d'interagir avec les développeurs, donc j'ai dû entrer dans toutes les solutions logicielles prêtes à l'emploi - ici vous ne pouvez pas tout écrire à partir de zéro )))), et les fabricants de "fer" industriel utilisent des systèmes de programmation spécialisés, où C, où SCADA, et l'assembleur, et chaque fois doit être en mesure de lire le code de quelqu'un d'autre ;))
Vous proposez de créer, sur la base de votre "moteur", une conception utilisable sous conditions, qui ne peut plus être modifiée par les programmeurs ?
Quelles sont les rancœurs ? Vous ne comprenez pas que l'échange de données entre MT et .dll est vieux comme le monde.
J'ai fait le .dll parce qu'auparavant il n'y avait pas de graphiques décents dans MT, je voulais des boutons et des panneaux.
des tables ? - bien dessiner des tableaux, des contrôles ? - dessiner.... Il est impossible de séparer la tâche. Dans le même Delphi, il existe de nombreux composants prêts à l'emploi, tant pour créer des bases de données que pour travailler avec elles.
I.e. de MT vous avez besoin seulement les données, et le reste fera un programme tiers, vous pouvez prendre votre mot pour elle, mais dans le même Delphi pour écrire le travail avec la base de données, avec la sortie dans les tableaux, les graphiques, etc travail pour un jour ;)
ZS : qu'est-ce qu'une donnée en MT ? = il ne s'agit que d'un tick et d'une barre, et il n'y a aucun intérêt à "courir" l'histoire à travers un .dll - il suffit de tout mettre dans un fichier une fois et de travailler avec ce fichier dans un programme tiers.
Si vous prenez uniquement les données provenant de MT et que vous les faites passer par une DLL vers une application écrite en Delphi, C++ ou C#, c'est certainement possible. L'application de trading sera alors entièrement écrite dans un langage de programmation différent.
En d'autres termes, les séries chronologiques, le testeur, l'optimisation, les synthétiques et bien d'autres choses doivent être créés dans un autre langage.
Pourquoi avez-vous besoin du MQL ? Il suffit de fournir les données directement à une application tierce, et d'utiliser la plateforme comme expéditeur d'événements et d'ordres. Et c'est tout. Mais les avantages de MQL en tant que langage de système de trading seront perdus.
Pourquoi avez-vous besoin de MQL ?
Parce que MQL est un langage d'application développé pour écrire des applications de trading. C'est son principal avantage. C'est léger et simple. Il dispose d'un grand nombre de solutions prêtes à l'emploi pour les programmeurs. Ils les prennent et les utilisent.
Les programmeurs ont le choix :
Évidemment, l'option la plus préférable est d'utiliser MQL et MT, car ils offrent des avantages - Test, Optimisation, Recherche (synthétique), Indicateurs, fonctions pratiques, séries temporelles... + Soutien linguistique technique sur le forum.
Mais cet idéal présente un grave défaut : une capacité limitée à créer des applications complexes, en raison de la difficulté à créer une interface graphique de qualité.
Ce dernier problème a été en grande partie résolu.
Par conséquent, lorsqu'il s'agira de mettre en pratique et de rédiger une demande sérieuse, vous choisirez certainement MT. Comme beaucoup, beaucoup d'autres.
...
Suggérez-vous de créer, sur la base de votre "moteur", une conception utilisable sous certaines conditions, qui ne peut être modifiée par les programmeurs ?
Le moteur est le "porteur" de cette interface graphique qui est créée dans mon constructeur. Il n'a pas besoin d'être modifié. Il suffit de le connecter à l'application pour que l'interface graphique créée fonctionne.
Encore une fois : si l'application est grande et sérieuse (tableaux, fenêtres de réglages, dialogues, listes anciennes, etc...) créer un fonctionnement unique, cohérent et efficace des deux parties via la DLL est une tâche TRÈS sérieuse. Je l'ai fait, et je sais de quoi je parle.
Quiconque peut créer une application importante et complexe utilisera certainement la bibliothèque gui. Que doit faire le développeur, s'il développe son application et décide d'ajouter une animation, par exemple ? Doit-il vous chercher et vous demander, ou doit-il tout casser et construire à partir de zéro ?
D'où vous vient l'idée qu'il y a un problème de création d'interface graphique. Regardez le marché, il y a beaucoup d'applications avec une interface graphique.
1. Quiconque peut créer une application importante et complexe utilisera certainement la bibliothèque gui.
2. Que doit faire le développeur si, pendant le développement de son application, il décide, par exemple, d'ajouter une animation ? Chercher pour vous et demander, ou tout casser et construire à partir de zéro ?
3) Et où avez-vous eu l'idée qu'il y a un problème avec la création de GUI. Regardez le marché, il y a beaucoup d'applications avec des interfaces graphiques.
1. La bibliothèque GUI est une bibliothèque conçue pour les programmeurs sérieux. Il ne peut être produit en masse en raison de sa difficulté d'utilisation. Quel est l'intérêt de cela ? Certains d'entre nous vont se plonger dans la bibliothèque et créer des applications complexes alors que d'autres n'en seront pas capables ?
2. Laissez le développeur créer une animation dans son application. Qu'est-ce que ça a à voir avec moi ? Il peut appeler cette animation indépendamment de l'interface graphique et du moteur, ou lier l'appel de son animation à un bouton.
3) Il n'y a que quelques personnes dont l'interface graphique est digne d'attention. Toi, Anatoly et peut-être quelqu'un d'autre... Les autres n'atteignent pas le moindre niveau de sérieux.
3. il n'y a que quelques personnes dont l'interface graphique est digne d'intérêt.
Je ne serais pas aussi catégorique. Et je ne parlais pas du développement de bibliothèques gui, je parlais des applications gui. Il y en a beaucoup sur le marché, certains utilisant leurs propres développements, d'autres la bibliothèque standard et d'autres encore la bibliothèque d'Anatoly.
1. C'est le but. La bibliothèque GUI est conçue pour les programmeurs sérieux. Il ne peut pas être diffusé massivement en raison de la difficulté d'utilisation. Quel est l'intérêt de cela ? Parmi ceux qui se plongeront dans la bibliothèque et créeront des applications complexes, certains échoueront ?
2. Laissez le développeur créer une animation dans son application. Qu'est-ce que ça a à voir avec moi ? Il peut appeler cette animation indépendamment de l'interface graphique et du moteur, ou lier l'appel de son animation à un bouton.
3) Il n'y a que quelques personnes dont l'interface graphique est digne d'attention. Toi, Anatoly et peut-être quelqu'un d'autre... Les autres n'atteignent même pas le moindre niveau de sérieux.
Peter, je pense que le principal problème que vous rencontrez réside dans le positionnement du projet.
Il ne peut intéresser que les participants qui ont une assez bonne expérience de la programmation, mais qui, en même temps, préfèrent échanger des coups de main.
Pensez-vous qu'ils sont nombreux ?
Ecoutez - toutes les personnes qui critiquent votre conception sont des personnes qui ne pratiquent pas le trading "manuel" de façon régulière. Tout au plus - de temps en temps. Et, comme ils ne considèrent pas votre projet comme des commerçants "manuels", ils le considèrent comme des programmeurs. Et, naturellement, ils trouvent beaucoup de solutions très douteuses.
À mon avis, votre question devrait maintenant porter sur la recherche de cette niche (à mon avis, très étroite) : les programmeurs qui préfèrent échanger leurs mains.
Je pense avoir vu un article quelque part, par exemple sur Hubra, intitulé "creating a GUI builder for Python", et je me suis dit que quelqu'un avait peut-être déjà vu une interface graphique multiplateforme dans laquelle je pouvais ajouter mon propre code.
Si je veux écrire un constructeur à partir de zéro, je préfère utiliser MQL.
Les constructeurs d'interface graphique modernes (ceux qui "étalent les boutons sur les formulaires") sont assez technologiques et leur rattacher des éléments MQL ne semble pas fantastique.
Dans la forme intermédiaire ( fichier de projet, etc.), la plupart d'entre eux ont un XML décrivant la disposition et les relations entre les éléments.
La génération du code de la plate-forme cible est en fait une transformation XSLT, qui peut être réalisée par quiconque se prend pour un développeur web :-)
Prenons par exemple EasyAndFast (https://www.mql5.com/ru/code/19703), car il est basé sur l'objet et possède tous les composants nécessaires. (et ouvert et documenté d'ailleurs, contrairement à ce qui se passe dans ce fil),
et écrire simplement un traducteur.
Il n'y a pas de constructeurs de gui-mql, non pas parce que c'est méga-complexe, mais simplement parce que ce n'est pas demandé.