Mon approche. Le noyau est le moteur. - page 25
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
Vous n'avez pas non plus de rappel dans MT. Tout est fait par des événements prédéfinis dans MT, qui une fois pour toutes.
Vous continuerez à envoyer des événements de terminal à la DLL, et l'endroit où vous les traitez, dans MT ou dans la DLL, n'a aucune importance.
Voici un exemple de mon interface de connexion :
C'est là que tout est déjà pensé.
Même si l'on imagine que la vérification constante des messages de Sharp par l'application ICL n'est pas une nuisance, le développement d'un format d'interaction est une tâche très volumineuse.
Cette tâche comprend les éléments suivants :
1. Mise en place d'une organisation de la mémoire partagée.
2. Mettre en œuvre l'interaction des trois parties.
3. Test synchrone des trois côtés (Sharp, DLL, application MT).
Cela prend beaucoup de temps.
Dans mon cas, l'utilisateur reçoit le fichier et le remplit. Et la connexion fonctionne.
N'inventez pas ça. Je fais cela depuis 8 ans avec différents terminaux et langages, de VBA Excel à C++, et je ne connais rien à ces problèmes).
J'ai déjà écrit que votre système est probablement applicable par des vendeurs de marché ou des personnes autres que MT-MQL qui ne savent rien de l'existence d'autres langages et environnements de programmation.
N'inventez pas ça. Je fais cela depuis 8 ans avec différents terminaux et langages, de VBA Excel à C++, et je ne connais rien à ces problèmes).
Jetez un coup d'œil à mon fichier de connexion.
L'utilisateur connecte simplement ce fichier via un inline à son EA. Et le remplit. Et tout fonctionne......
J'ai déjà écrit que votre système est probablement applicable par des vendeurs du marché ou des personnes autres que MT-MQL qui ne savent rien de l'existence d'autres langages et environnements de programmation.
Au fait, je suis en train de développer des connexions GUI avec l'EA dans le testeur. L'interface graphique sera sur un graphique et l'EA sera exécuté dans le testeur. Et ils communiqueront entre eux. Le conseiller expert du testeur de stratégie répondra aux actions de l'utilisateur sur un graphique différent qui interagira avec l'interface graphique.
J'ai trouvé comment mettre cela en œuvre.
Mais pour établir la communication entre l'Expert Advisor dans le Strategy Tester et le Sharp via la DLL... Cela ne semble pas être possible.
Et pour établir un lien entre l'EA dans le testeur et Sharpe via la DLL... Je ne pense pas que tu puisses.
Cela semble possible. Le testeur, pour autant que je sache, n'impose aucune restriction à la communication avec la DLL. Cependant, je ne l'ai pas essayé moi-même.
Cela semble possible. Le testeur, pour autant que je sache, n'impose aucune restriction à la communication avec la DLL. Cependant, je ne l'ai pas essayé moi-même.
Eh bien, peut-être que tu peux... Cependant, le choix "masochiste" envers Sharp est trop évident)))) Il y a tellement de nuances... Mais quand il n'y a pas le choix, bien sûr.
Je n'ai jamais écrit en Sharpe, 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, tout fonctionnait sans problème, et j'ai même écrit tout le projet en Delphi en une journée, de plus j'ai passé une demi-journée à essayer de trouver la raison pour laquelle les formulaires standard ne fonctionnaient pas, et 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 : notez que Delphi n'est pas assez pratique pour créer des .dll, mais ce que j'avais sous la main (ce sur quoi j'étais assis à l'époque), je l'ai utilisé ;))).
Mais 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. Tout au plus serait-il intéressant d'unifier le processus de création graphique, peut-être s'agirait-il d'un include universel où l'on pourrait commenter les boutons/dialogues, etc.
Pouvez-vous suggérer un constructeur d'interface graphique gratuit qui permettrait d'écrire le code MQL pour les graphiques ?
Je veux faire quelque chose de similaire à Delphi Drag-and-Drop, mais je n'ai pas trouvé de constructeur GUI libre, qui permettrait d'entrer le code MQL.
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.