Création d'une interface graphique pour les MQL en mode graphique. - page 10
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
Polling unidirectionnel à partir de μl, pips, fichiers ou requêtes web.
Je suis sûr que ce serait très bien ! Il ne s'agit pas d'envoyer quoi que ce soit à MT. Le transfert lui-même peut être effectué de toute autre manière. L'important est d'indiquer à MT qu'une action doit être effectuée. C'est exactement la même chose que dans la bibliothèque GUI que vous avez développée : tous les colbecs sont effectués par le biais d'événements.
Au fait, à propos de cette bibliothèque : prévoyez-vous de l'étendre et de la traduire entièrement en toile ? Autrement dit, le "produit" final n'est pas un ensemble d'objets graphiques, mais une image complète.
Et dans le contexte de l'examen des dll, j'aimerais bien sûr pouvoir inclure la dll en tant que ressource dans MT, afin que nous n'ayons pas à les "glisser" avec le conseiller expert ou l'indicateur.
Pourquoi s'arrêter à dotnet pour les gui ?
La question ne porte pas tant sur l'interface graphique. Les interfaces peuvent être facilement créées à l'aide d'outils de TA. Bien sûr, c'est un peu compliqué et nécessite la création de classes de traitement propres, mais tout peut être résolu. J'ai commencé à travailler avec le réseau en raison de l'impossibilité de mettre en œuvre certains algorithmes de travail avec Internet. C'est plutôt compliqué et instable en C++, même en langue maternelle, sans parler de MT. Une fois que j'aurai maîtrisé le réseau, je pourrai commencer à utiliser l'interface graphique également, car tout est prêt pour cela, contrairement à MT. Parmi les questions ouvertes du développement d'applications dans n'importe quel langage, à savoir dans n'importe quel, car ces questions ne sont pas liées au réseau : 1. Feedback, 2. Lier l'interface graphique au graphique (https://www.mql5.com/ru/forum/103764)-un des sujets.
Interrogation unidirectionnelle à partir de µl, pips, fichiers ou requêtes web.
c'est votre choix ;-)
du point de vue des applications - il devrait y avoir un moyen standard, après l'appel de la DLL, de répondre à MT "c'est ce que vous voulez, c'est ce que vous obtenez".
Scénario typique pour les longs calculs, IO réseau - MT appelle DLL, DLL crée un thread et quelque chose est fait dans ce thread. Il doit y avoir un moyen de dire "c'est tout, ça a été calculé". Sans cela, nous sommes constamment en train d'interroger les AE pour quelque chose.
c'est votre choix ;-)
Du point de vue des applications, il devrait y avoir un moyen standard de dire à MT "voilà ce que vous voulez, voilà ce que vous obtenez".
Scénario typique pour les longs calculs, les entrées/sorties réseau : MT appelle la DLL, la DLL génère un thread et quelque chose est fait dans ce thread. Il doit y avoir un moyen de dire "c'est tout, ça a été calculé". Sans elle, nous sommes constamment en train de demander quelque chose à l'EA.
Je suis d'accord avec vous !
Bien
Nous pouvons tous débattre jusqu'au bout des mérites d'un environnement de développement ou d'un autre. Mais pour quoi faire ? Nous savons tous qu'aucun système de développement n'est autosuffisant, car il résout des problèmes spécifiques. Tout autre composant plug-in développé dans un autre langage ou environnement peut être utilisé pour étendre ses capacités. Nous devons simplement faire en sorte que la communication soit facile. N'allons pas trop loin : les mêmes bibliothèques Windows que nous utilisons en important... ...nous les utilisons pour implémenter la fonctionnalité qui nous manque. Et vous ne pouvez pas dire qu'il est mis en œuvre uniquement au moyen de mql. ))) Alors quelle différence cela fait-il de savoir quelle application externe nous utilisons pour étendre les capacités et atteindre les objectifs souhaités ? En quoi une dll auto-écrite est-elle pire qu'une dll Windows ?
Voici un article à titre d'exemple : https://www.mql5.com/ru/articles/364
Mais il ne s'agit pas de se débarrasser complètement de dll, cela n'arrivera tout simplement jamais, car MT a strictement ses propres tâches. Dans cet article, les bibliothèques système sont présentes, quelle que soit la façon dont on les considère. Oui, contrairement aux bibliothèques faites maison, ces bibliothèques n'ont pas besoin d'être transportées avec un conseiller expert ou un indicateur...
Et bien, qu'est-ce qui vous empêche d'ajouter la possibilité de compiler des dlls dans les ressources de l'outil ?
Oui, vous ne pouvez pas le mettre sur le marché, car le marché n'autorise pas l'utilisation de dll, mais ce serait beaucoup plus pratique pour votre propre développement.
Nous pouvons tous débattre jusqu'au bout des mérites d'un environnement de développement ou d'un autre. Mais pour quoi faire ? Nous savons tous qu'aucun système de développement n'est autosuffisant, car il résout des problèmes spécifiques. Tout autre composant plug-in développé dans un autre langage ou environnement peut être utilisé pour étendre ses capacités. Nous devons simplement faire en sorte que la communication soit facile. N'allons pas trop loin : les mêmes bibliothèques Windows que nous utilisons en important... ...nous les utilisons pour implémenter la fonctionnalité qui nous manque. Et vous ne pouvez pas dire qu'il est mis en œuvre uniquement au moyen de mql. ))) Alors quelle différence cela fait-il de savoir quelle application externe nous utilisons pour étendre les capacités et atteindre les objectifs souhaités ? En quoi une dll auto-écrite est-elle pire qu'une dll Windows ?
Voici un article à titre d'exemple : https://www.mql5.com/ru/articles/364
Mais il ne s'agit pas de se débarrasser complètement de dll, cela n'arrivera tout simplement jamais, car MT a strictement ses propres tâches. Dans cet article, les bibliothèques système sont présentes, quelle que soit la façon dont on les considère. Oui, contrairement aux bibliothèques faites maison, vous n'avez pas besoin de porter ces bibliothèques avec un conseiller expert ou un indicateur...
Et bien, qu'est-ce qui vous empêche d'ajouter la possibilité de compiler des dlls dans les ressources de l'outil ?
Oui, vous ne pouvez pas le mettre sur le marché, car le marché ne permet pas l'utilisation de dll, mais pour votre propre développement, ce serait beaucoup plus pratique.
Ces pensées et ces messages ont 10 ans.
Si nous parlons de l'écosystème, alors nous devrions simplement interdire l'utilisation de toute importation dans MT. Mais ils ne le font pas. Après tout, ils n'ont pas décidé d'utiliser les importations de la bibliothèque pour une simple raison. Pendant un certain temps, MT ne pouvait pas travailler avec des requêtes web, il y avait des limitations pour travailler avec des fichiers... tout cela a été EXPANDI par l'importation de bibliothèques. C'est évident et tous les systèmes fonctionnent de cette façon. Même maintenant, MQL ne peut travailler avec des fichiers que depuis un bac à sable. Ce n'est pas comme si quelqu'un contestait cette approche, c'est la politique du développeur et tout le monde la comprend et la soutient. Si vous avez besoin de sortir d'un bac à sable ou d'utiliser un registre pour stocker des données, ou une base de données ou une cartographie ... alors veuillez utiliser des bibliothèques à cette fin. N'est-ce pas ? Tout cela est parfaitement logique. L'outil n'a pas besoin de bases de données ou de quoi que ce soit d'autre... tout cela est réservé aux développeurs, c'est pourquoi le langage MQL est disponible, afin que vous puissiez mettre en œuvre des outils de n'importe quelle fonctionnalité. Et comme il y a un environnement de développement, MT n'est plus une chose en soi. )) Vous avez juste besoin de ... ))))
Ce genre de réflexions et de messages ont 10 ans, mais nous sommes toujours là...
Comment cela peut-il être encore le cas ?
Toutes les possibilités d'interopérabilité existent depuis longtemps. La prise en charge des DLL a même été introduite en 2004.
Nos langages évoluent constamment et deviennent plus puissants et plus fonctionnels. Et l'écosystème est plus puissant que celui de n'importe qui d'autre.