Création d'une interface graphique pour les MQL en mode graphique. - page 9
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
Maintenant tu peux juste l'affiner.)
Toujours rien que des émotions.
Alexey, qu'est-ce que tu veux ? Tu es un peu confus après des événements heureux :-)
Pas d'émotion - votre amour pour .net est un produit de la gestion et de l'émotion. Vous devez peser le pour et le contre avant de prendre une technologie et vous courez comme des lemmings.
c .netproject requires 2 shells for development ( MT and VS ) . Un goulot d'étranglement C++ peut être créé sans quitter l'environnement commun.
Le débogage d'une dll .net exécutée à partir de MT5, avec une protection croissante contre le débogage et le traçage, est peut-être facile, mais je n'en ai personnellement pas besoin.
Les superpositions sur les appels DLL, elles sont là aussi. Et au moment de l'exécution du modèle, lorsque MT ne fait que sonder, ils sont très sensibles. Si nous exécutons le calcul de l'hypercube dans la DLL, nous ne le remarquerons pas.
Mais si vous êtes constamment en train d'interroger le formulaire pour savoir si l'utilisateur a appuyé sur OK, alors uh-oh. Et chez vos scalpeurs préférés :-)
Toujours rien que de l'émotion.
Alexei, qu'est-ce que tu veux ? Tu es un peu confus après les joyeux événements :-)
Pas d'émotion - votre amour pour .net est un produit de la gestion et de l'émotion. Vous devez peser le pour et le contre avant de prendre une technologie et vous courez comme des lemmings.
Un projet .net nécessite 2 shells pour le développement ( MT et VS) . C++ netleneck peut être développé sans quitter l'environnement commun.
Le débogage des dll .net, lancées à partir de MT5, avec une protection croissante contre le débogage et le traçage, peut être facile, mais je n'en ai personnellement pas besoin.
Les superpositions sur les appels DLL, elles sont là aussi. Et au moment de l'exécution du modèle, lorsque MT ne fait que sonder, ils sont très sensibles. Si nous exécutons le calcul de l'hypercube dans la DLL, nous ne le remarquerons pas.
Mais si vous êtes constamment en train d'interroger le formulaire pour savoir si l'utilisateur a appuyé sur OK, alors, oh, oh. Et chez vos scalpeurs préférés :-)
Maxim, en ce qui concerne le retour d'information, cela ne fait aucune différence que vous utilisiez net ou C++. Par exemple, vous avez implémenté une interface graphique en Tcl. Après tout, vous avez aussi un problème de retour d'information. Il ne dépend pas de l'environnement de développement. Si vous essayez d'héberger l'interface graphique sur un graphique, le même problème de rendu se posera. Ce n'est pas comme s'il y avait une discussion sur les performances dans ce fil de discussion. C'est une question de goût, essentiellement.
L'ignorance donne confiance. Mais le savoir multiplie les peines.
Renat, puisque tu t'es "mis dans le bain", peux-tu me dire comment mettre en place un retour d'information entre une application tierce, peu importe l'environnement dans lequel elle est écrite, même en C++, avec MT.
Renat, puisque tu t'es "penché" sur le sujet, pourrais-tu me dire comment mettre en place un retour d'information entre une application tierce, quel que soit l'environnement dans lequel elle est écrite, même si c'est du C++, avec MT.
C'est impossible. Même au sein de MT, tout n'est que prédéfini. Événements MQ.
Eh bien, à MT, c'est plus facile, par le biais d'événements. Si un événement se produit, nous exécutons la commande, s'il n'y a pas d'événement, nous nous reposons. Et l'utilisation d'un timer pour saccader une application externe, quel que soit le support sur lequel elle est écrite, n'est pas très pratique. De plus, contrairement à net, MT n'a pas de fils. La minuterie ainsi que les événements se déroulent tous dans un seul et même thread, ce qui impose les restrictions correspondantes. S'il était possible d'appeler le même OnChartEvent depuis l'extérieur, de nombreuses questions pourraient être résolues. En fait, je ne comprends pas pourquoi il est interdit d'appeler cette méthode. Après tout, MT intercepte les événements de l'environnement : mouvement de la souris, clics du clavier ou de la souris... Donc, dans ce sens, les événements interagissent avec le windup, alors on ne voit pas pourquoi un événement utilisateur ne pourrait pas être acheminé là aussi. Ce serait un magicien universel.
Eh bien, à MT, c'est plus facile, par le biais d'événements. Si un événement survient, nous exécutons l'ordre, s'il n'y a pas d'événement, nous nous reposons. Mais il n'est pas très pratique de tirer de manière intempestive une application externe, quel que soit le support sur lequel elle est écrite. De plus, contrairement à net, MT n'a pas de fils. La minuterie et les événements se déroulent tous dans un seul fil, ce qui impose des restrictions correspondantes.