Création d'une interface graphique pour les MQL en mode graphique. - page 12

 
Yuriy Asaulenko:
En fait, je ne le fais pas. Il n'y a aucune différence entre un programme externe et un programme dans MT. Les capacités sont les mêmes, l'interaction est la même.
Bien sûr, il n'y a pas assez de colbacs, mais il n'y en a pas non plus dans le MT.
Mais en général, c'est possible. Deuxième EA et mutex ou temporisateur court. Cela fonctionne, mais ce n'est pas nécessaire.

Vous n'avez rien expliqué du tout. Comment obtenir les données de MT* dans le panel Sharpe ?

J'ai procédé à un retour d'information par le biais de la cartographie de la mémoire avec des sondages chronométrés. Le panneau ne m'a envoyé que des paramètres différents et des résultats de calcul lents.

 
Renat Fatkhullin:
L'ignorance donne confiance. Mais la connaissance multiplie les peines.

Ça vous dérangerait quand :
- une machine virtuelle extraterrestre et énorme s'introduit dans votre processus
- détourne vos extraits et se prend pour le maître.
- consomme beaucoup de mémoire et pense qu'il est le maître.
- gérer un tas de fils qui ont une vie propre.
- Le collecteur de déchets se développe au maximum et limite votre processus.
- tous les appels à travers le wrapper.

Pour le bien de la GUI, c'est vraiment exagéré.

Ok, alors je vais rendre le panneau séparé, communication via Memory Mapping. J'avais l'habitude de le faire via des tuyaux à la fin des années 2000, mais je n'aimais pas ça.

Connecté directement, je n'ai pas remarqué d'horreurs.

 
Maxim Kuznetsov:

L'interface COM du terminal serait cool, bien qu'elle devienne rapidement obsolète.

Cela ne semble pas correspondre au temps réel :-(.

L'interface COM ne sera probablement pas disponible.

Mais puis-je demander pourquoi il est obsolète ?

Il est également en train de devenir rapidement obsolète.

 
Koldun Zloy:

L'interface COM ne sera probablement pas disponible.

Mais puis-je demander pourquoi elle est obsolète ?

Il est également en train de devenir rapidement obsolète.

il a été remplacé par .net avec ses interfaces de communication

 
Alexey Volchanskiy:

il a été remplacé par .net avec ses interfaces de communication

et dans COM, les GUIDs valent à eux seuls beaucoup.

MS rachète toujours les GUIDs inutilisés pour un dollar par 10. Si vous avez des restes d'autrefois, vous pouvez faire un joli bénéfice !

 
Alexey Volchanskiy:

et dans COM, les GUIDs valent à eux seuls beaucoup.

MS rachète toujours les GUIDs inutilisés pour un dollar et dix cents. Si vous avez des restes de l'ancien temps, vous pouvez gagner beaucoup d'argent !

J'en ai quelques-uns qui traînent :-) Je vous laisse les envoyer à MS.

066cd265-e2fe-468e-9492-4228e9759e38
8e1040ba-dc3e-4e2a-9208-e3ea8da9ad05
03dcd7cd-4b9b-4ff7-bff0-e0839a0f9d8b
d69f2c8c-de51-4557-8188-4ebb870da7da
a79a8cc6-f785-4268-bc4e-2deda0f1ecd0
f4f59f52-1da8-4f74-a71e-9aec1992674d
85608797-6015-456d-af64-ad7890120372
9289991a-e287-47fb-b595-6d719c1b7dbd
63d3b953-3229-4045-a82a-fc9e7795bb01
c75c4e0f-8320-42df-943c-9aada54b60eb

s'il y a autre chose, je pourrais le trouver.

 

Collègues. Je pense que l'argument concernant le meilleur environnement de développement et le code le plus rapide n'a aucun sens. C'est une question de goût et cela dépend des tâches à accomplir. Quel que soit l'environnement de développement, nous avons toujours des problèmes d'interaction entre une application externe et un outil MetaTrader. Prenons un exemple simple. Vous avez implémenté dans une dll native un algorithme de calculs mathématiques complexes. Vous avez transmis les paramètres requis de l'outil MT à cette bibliothèque et lancé le calcul, l'outil a continué son travail jusqu'à ce que le calcul soit terminé. Et encore une fois, ce problème ne dépend pas de l'environnement de développement !

Je vois plusieurs options :

1. La possibilité d'appeler depuis l'extérieur du programme la méthode OnChartEvent, en utilisant par exemple la méthode PostMessage.

2. Ajout aux outils МТ d'une nouvelle méthode, comme Renat l'a proposé : OnExternal, en spécifiant le type d'événement ou les données généralement transférées, c'est-à-dire que dans cette méthode, vous pouvez retourner les données.

3. Mise en œuvre dans les outils de MT de winsocket. Ceci est similaire au deuxième point, mais permet à l'outil MT de se connecter à un port spécifique pour écouter les données.

Si les premier et deuxième éléments permettront une interaction au niveau d'une seule machine, le troisième élément fournira des outils de TA avec une communication en réseau.

Voici un exemple: https://www.mql5.com/ru/articles/2599

Mais là encore, le problème est de devoir vérifier si les données sur la prise sont disponibles en permanence.

Le problème du rappel demeure donc dans tous les cas et il n'est pas résolu.

La surveillance par minuterie n'est pas une solution mais une béquille. Oui, en l'absence d'autres options, c'est ainsi que nous résolvons le problème maintenant.

Si les développeurs mettaient en œuvre une solution pour ces problèmes au niveau de la plate-forme, il ne serait pas nécessaire d'accéder à l'API du terminal. Après tout, on ne le demande pas pour la bonne vie, mais parce qu'il n'y a pas d'interaction à part entière entre MT et les applications créées. Et je le répète : ce problème existe quel que soit l'environnement de développement d'applications externes choisi.

Работа с сокетами в MQL, или Как стать провайдером сигналов
Работа с сокетами в MQL, или Как стать провайдером сигналов
  • 2016.07.12
  • ---
  • www.mql5.com
Сокеты… Что вообще сейчас в нашем информационном мире может без них существовать? Впервые появившиеся в 1982 г. и практически не изменившиеся до настоящего времени, они исправно работают на нас каждую секунду. Это основа сети, нервные окончания нашей Matrix, в которой мы живем. Утром вы включили терминал MetaTrader, и он сразу создал сокеты и...
 

Informations sur la possibilité d'utiliser les net-bibliothèques ;)))https://www.mql5.com/ru/forum/13388

Le sujet est très ancien dans son principe. Les développeurs eux-mêmes ont un jour annoncé la possibilité de travailler avec les bibliothèques du Net sans aucune difficulté... Depuis, beaucoup d'eau a coulé sous les ponts, mais la question n'est toujours pas résolue...

Ou ici, un message de Renat lui-même: https://www.mql5.com/ru/forum/3153/page2#comment_298866

https://www.mql5.com/ru/forum/3153/page2#comment_298892

Встроенная поддержка .NET библиотек
Встроенная поддержка .NET библиотек
  • 2013.08.12
  • www.mql5.com
NET библиотеках функции могут быть только static методами или методами экземпляров класса.
 
Алексей Барбашин:

Collègues. Je pense que l'argument consistant à déterminer quel environnement de développement est le meilleur et quel code est le plus rapide n'a aucun sens. C'est une question de goût et cela dépend des tâches à accomplir. Quel que soit l'environnement de développement, nous avons toujours des problèmes d'interaction entre une application externe et un outil MetaTrader. Prenons un exemple simple. Vous avez implémenté dans une dll native un algorithme de calculs mathématiques complexes. Vous avez transmis les paramètres requis de l'outil MT à cette bibliothèque et lancé le calcul, l'outil a continué son travail jusqu'à ce que le calcul soit terminé. Et encore une fois, ce problème ne dépend pas de l'environnement de développement !

Je vois plusieurs options :

1. La possibilité d'appeler depuis l'extérieur du programme la méthode OnChartEvent, en utilisant par exemple la méthode PostMessage.

2. Ajout aux outils МТ d'une nouvelle méthode, comme Renat l'a proposé : OnExternal, en spécifiant le type d'événement ou les données généralement transférées, c'est-à-dire que dans cette méthode, vous pouvez retourner les données.

3. Mise en œuvre dans les outils de MT de winsocket. Ceci est similaire au deuxième point, mais permet à l'outil MT de se connecter à un port spécifique pour écouter les données.

Si les premier et deuxième éléments permettront une interaction au niveau d'une seule machine, le troisième élément fournira des outils de TA avec une communication en réseau.

Voici un exemple: https://www.mql5.com/ru/articles/2599

Mais là encore, le problème est de devoir vérifier si les données sur la prise sont disponibles en permanence.

Le problème du rappel demeure donc dans tous les cas et il n'est pas résolu.

La surveillance par minuterie n'est pas une solution mais une béquille. Oui, en l'absence d'autres options, c'est ainsi que nous résolvons le problème maintenant.

Si les développeurs mettaient en œuvre une solution à ces problèmes au niveau de la plate-forme, il ne serait pas nécessaire d'accéder à l'API du terminal. Après tout, on ne le demande pas pour la bonne vie, mais parce qu'il n'y a pas d'interaction à part entière entre MT et les applications créées. Et je le répète : ce problème existe quel que soit l'environnement de développement d'applications externes choisi.

J'ajouterai à propos de la surveillance et de l'interrogation, mais tout le monde ne le sait pas - pour éviter de secouer la DLL à chaque interrogation, vous pouvez avoir int[] pour "partager" les drapeaux. A l'intérieur de la DLL, tous les accès sont des __atomiques__ .
En principe, cela fonctionne et est assez économe en ressources, mais vous devez compter sur le fait que du côté de MQL, l'incrémentation/décrémentation sont également atomiques et que l'optimiseur ne fait pas d'hypothèses sur les valeurs.



int flags[1]={0};     // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] )   // проверить один int это очень быстро
{
   flags[0]--;
   ReadDataFromDLL(handle);
}

Pour que les choses soient vraiment bonnes, un attribut atomique (volatile ?) et un ensemble de primitives appropriées seraient suffisants. À mon avis, il est plus facile d'intégrer un nouveau mécanisme dans le système et de ne pas modifier le protocole DLL existant.

 
Maxim Kuznetsov:

J'ajouterai à propos de la surveillance et de l'interrogation, que tout le monde ne connaît pas - pour ne pas ennuyer la DLL avec chaque interrogation, vous pouvez créer des int[] pour "partager" les drapeaux. A l'intérieur de la DLL, tous les accès sont des __atomiques__ .
En principe, cela fonctionne et est assez économe en ressources, mais vous devez compter sur le fait que du côté de MQL, l'incrémentation et la décrémentation sont également atomiques et que l'optimiseur ne fait pas d'hypothèses sur les valeurs.



int flags[1]={0};     // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] )   // проверить один int это очень быстро
{
   flags[0]--;
   ReadDataFromDLL(handle);
}

Pour que les choses soient vraiment bonnes, un attribut atomique (volatile ?) et un ensemble de primitives appropriées seraient suffisants. À mon avis, il est plus facile d'intégrer un nouveau mécanisme dans le système et de ne pas modifier le protocole DLL existant.

Maxim, en quoi cette solution est-elle meilleure ? Après tout, pour vérifier l'état d'un drapeau, il faut aussi le vérifier périodiquement dans MQL. Il s'avère donc que partout où vous regardez, vous devez surveiller constamment les changements d'état de quelque chose pour comprendre qu'il est temps de ramasser les données. Et ce fragment peut être stocké dans la dll elle-même et vérifié là - c'est ce que je fais. Dans votre exemple, nous avons un appel implicite à la dll pour retourner l'état du drapeau.