Développement d'une bibliothèque de fonctions API pour MetaTrader 4 - page 5

Nouveau commentaire
 
D'ailleurs, maintenant, ce que propose Min ressemble plus qu'avant à ce que vous pouvez acheter. <br / translate="no">Purement imho :)

Merci ! Nous attendons avec impatience les suggestions commerciales. Bonne chance !
 
Il est difficile d'appeler cela une API. Bibliothèque + EA. Fonctionne TRES lentement.
 
...
 
Question au développeur de la bibliothèque : pourquoi la vitesse d'obtention des citations lors de l'utilisation de votre bibliothèque est-elle encore plus lente que lors de l'utilisation des fichiers temporaires ? Quel est alors l'avantage d'utiliser la mémoire partagée ? <br/ translate="no">

Qu'entendez-vous par rapidité d'obtention des devis ? S'il s'agit d'obtenir des ticks, j'ai déjà écrit que travailler avec des ticks de cotations, même directement dans MT4, est difficile.
La bibliothèque n'a pas été conçue à l'origine pour attraper les tiques. Cela est dû au fait que le système peut tout simplement se bloquer lorsque le marché est très actif, car il ne peut pas suivre les ticks. C'est pourquoi la bibliothèque dispose d'une protection logicielle intégrée contre l'avalanche de tiques.
Les avantages de l'utilisation de la mémoire partagée sont la grande fiabilité d'un tel système et l'absence d'encombrement des disques durs. En outre, plusieurs programmes peuvent accéder à la bibliothèque, et ils n'ont pas besoin de "connaître" l'emplacement exact des fichiers temporaires. Bonne chance !
 
Lorsque le marché est très actif, le système peut tout simplement se bloquer en raison de son incapacité à suivre les ticks.
C'est
pourquoi la bibliothèque contient une protection logicielle intégrée contre l'avalanche de ticks.


il semble que l'auteur ait exagéré :)
d'après ce que j'ai compris, si l'EA est à l'intérieur de la fonction start() (et qu'il envoie des informations sur un tick au client API à partir de là), alors MT ne donnera pas de nouveau tick avant que l'EA ne quitte la fonction start(). C'est pourquoi il n'est pas clair comment une avalanche de ticks peut se produire ?

si l'EA est bouclé et reçoit des ticks via RefreshRates, alors il doit d'abord sortir de l'API client, et ensuite l'appel de RefreshRates se produira. C'est pourquoi il n'y a pas non plus d'endroit où geler ici.

L'avantage d'utiliser la mémoire partagée est la grande fiabilité d'un tel système.

Cela semble bien, mais ce n'est pas le seul moyen de communication inter-processus.
donc le sujet "Quel est l'intérêt de l'utilisation de la mémoire partagée ?" n'est pas résolu :)

à mon avis, MMF n'est bon que dans un seul cas, lorsque vous avez besoin de pomper de grandes quantités de données entre les processus - la vitesse de pompage est de ~150Mb/sec. (il y a quelques mois, j'ai dû réaliser ce mécanisme uniquement avec MMF, car d'après les tests, c'est le moyen le plus rapide).

dans cette tâche (transfert des paramètres pour OrderSend, etc.) - c'est comme un oiseau dans une plume, plus facile de créer une fenêtre et d'utiliser SendMessage avec wm_copydata.
 
semble solide, mais ce n'est pas le seul moyen de communication interprocessus. <br / translate="no"> donc le sujet "...Quel est l'avantage d'utiliser la mémoire partagée alors ?" n'est pas résolu :)

Je ne pense pas que je soutiens que l'algorithme utilisé est le meilleur. C'est toute la beauté de la programmation : un tel problème peut être résolu d'au moins une douzaine de façons. La variante avec les fichiers temporaires fonctionnait également parfaitement. Ma tâche consistait à développer un substitut fiable, exploitable et entièrement fonctionnel de l'API MT3. La bibliothèque travaille maintenant avec le programme d'échange pratique depuis environ six mois. Et le principal problème ici n'était pas l'atteinte de la vitesse maximale, mais la fiabilité et la réponse adéquate à un grand nombre de situations d'urgence. Alors, merci pour vos commentaires, ils sont tout à fait appropriés, mais c'est "une autre histoire". Bonne chance !
 
Bonjour, le principal problème pour le moment est la connexion :

Inclure la bibliothèque d'importation Mforex2.lib dans le projet (pour Delpi - juste décrire les fonctions de la bibliothèque),
Spécifier le fichier d'en-tête Mforex.h dans le programme principal (par exemple : #include "Mforex.h" - seulement pour Builder C++) ;

Ces 2 points sont mystérieux pour moi parce que Omega est un programme prêt, tous les autres fichiers que j'ai placés comme décrit, j'ai prescrit la fonction pour démarrer MT4, et au démarrage j'ai eu le message qu'il est nécessaire de prescrire le chemin exact, mais j'ai aussi prescrit le chemin. Je ne sais pas quoi faire ensuite.
 
Inclure dans le projet la bibliothèque d'importation Mforex2.lib (pour Delpi - décrire uniquement les fonctions de la bibliothèque),<br/ translate="no"> Spécifier dans le fichier d'en-tête du programme principal Mforex.h (par exemple : #include "Mforex.h" - seulement pour Builder C++) ;
Ces 2 points me laissent perplexe car Omega est un programme prêt à l'emploi, j'ai placé tous les autres fichiers comme décrit, j'ai prescrit la fonction de démarrage de MT4 et au démarrage j'ai reçu le message qu'il est nécessaire de prescrire le chemin exact, mais j'ai prescrit le chemin aussi. Je ne sais pas quoi faire ensuite.

Omega a la possibilité d'importer des fonctions à partir de DLLs externes. Par conséquent, vous devez spécifier Mforex2.dll comme bibliothèque externe. En même temps, ce fichier doit se trouver dans le "champ de vision" des programmes Omega. Dans les procédures d'appel, indiquez le nom des fonctions importées de la DLL, comme indiqué dans la documentation. Notez également que Omega "ne connaît pas" les définitions du fichier Mforex.h. C'est-à-dire que, par exemple, lorsque vous appelez la fonction d'ouverture d'une position, vous devez spécifier le code d'opération pour, disons, Vendre - 1, plutôt que OP_SELL, etc. Pour plus de détails, consultez la documentation DevKit, qui décrit la manière dont omega fonctionne avec les bibliothèques externes.
Bonne chance !
 
<br / translate="no">Il est possible d'importer des fonctions à partir de DLL externes dans Omega. Par conséquent, Mforex2.dll doit être spécifié comme une bibliothèque externe. En même temps, ce fichier doit être "en vue" des programmes Omega. Dans les procédures d'appel, indiquez le nom des fonctions importées de la DLL, comme indiqué dans la documentation. Notez également que Omega "ne connaît pas" les définitions du fichier Mforex.h. C'est-à-dire que, par exemple, lorsque vous appelez la fonction d'ouverture d'une position, vous devez spécifier le code d'opération pour, disons, Vendre - 1, plutôt que OP_SELL, etc. Pour plus de détails, consultez la documentation DevKit, qui décrit la manière dont omega fonctionne avec les bibliothèques externes.
Bonne chance !


J'ai donc prescrit ce qui suit à Omega :

DefineDLLfunc : "Mforex2.dll", int, "Start" ; {Appel DLL}
_gbp = Start() ; {fonction de démarrage du terminal}

Mais vous dites qu'ici nous devrions écrire quelque chose d'autre au lieu de "Start()", ai-je bien compris ?
 
<br/ translate="no">J'ai donc prescrit ce qui suit à Omega :

DefineDLLfunc : "Mforex2.dll", int, "Start" ; {call DLL}
_gbp = Start() ; {fonction de démarrage du terminal}

Mais vous dites qu'au lieu de "Start()", il faut écrire autre chose, ai-je raison ?

Je me réponds : il ne faut pas écrire autre chose à la place de "Start()" - c'est exact, Omega démarre MT4 sans aucun problème.

Mais c'est un peu plus compliqué dans la fonction d'ouverture de position, j'ai donc prescrit la fonction :

Entrée : Symbol(NumericSimple), Order(NumericSimple), Lot(NumericSimple),
price(NumericSimple), sl(NumericSimple), tp(NumericSimple) ;


DefineDLLfunc : "Mforex2.dll", int, "NewPos",char, int, int, double, double, double ;

_NewPos = NewPos(Symbol, Order, Lot, price, sl, tp) ;

Logiquement, tout correspond à la description du fabricant, mais en pratique, nous avons des problèmes : tout est défini en chiffres...
1234567
Nouveau commentaire