Bibliothèque: Expert - page 7

Nouveau commentaire
 

Contrairement à MT4, MT5 n'enregistre pas les paramètres d'entrée des Expert Advisors lorsqu'ils sont lancés ou modifiés. Il est donc impossible de déterminer à partir du journal ce qui a été lancé dans le terminal.

Une fonction similaire peut corriger cette situation.

#include <fxsaber\Expert.mqh> // https://www.mql5.com/fr/code/19003

// Produit les données de l'EA en cours d'exécution
string EAToString( const long Chart_ID = 0 )
{
  string Names[];
  MqlParam Params[];
  
  const int Flag = EXPERT::Parameters(Chart_ID, Params, Names);
  const int Size = ArraySize(Names);
  
  string Str = "Expert " + Params[0].string_value + ", expertmode = " + (string)Flag;
  
  for (int i = 0; i < Size; i++)
    Str += "\n" + Names[i] + " = " + Params[i + 1].string_value;
    
  return(Str);    
}


Application

input int inInput1 = 1;
input int inInput2 = 2;

int OnInit()
{
  Print(EAToString());
  
  return(INIT_FAILED);
}


Résultat

Test8 (EURUSD,M1)       Expert Experts\Test8.ex5, expertmode = 4
Test8 (EURUSD,M1)       inInput1 = 1
Test8 (EURUSD,M1)       inInput2 = 2


Malheureusement, cela ne fonctionne pas pour les scripts. MT4 affiche lui-même les paramètres d'entrée des scripts, ce qui n'est pas le cas de MT5.

 
Je ne peux pas exécuter un EA qui utilise des DLL à l'aide de cette bibliothèque. Dans les journaux, le chargement de DLL n'est pas autorisé. Y a-t-il quelque chose que l'on puisse faire à ce sujet ?
 
pivomoe:
Je ne peux pas exécuter un EA qui utilise des DLL à l'aide de cette bibliothèque. Dans les journaux, le chargement de DLL n'est pas autorisé. Y a-t-il quelque chose que l'on puisse faire à ce sujet ? 
Params[0].string_value += "\nexpertmode=5"; // Permission d'utiliser la DLL
 
fxsaber:

Cela fonctionne.

 
J'ai vérifié le travail de la bibliothèque avec le groupe d'entrée. Tout est correct, je n'ai pas eu besoin de modifier le code.
 

Une chose que j'appréhende est le principe de l'utilisation d'une constante comme nom d'un modèle temporaire dans une chaîne de caractères :

#define  FILENAME (__FILE__ + ".tpl")

contient un bogue potentiel lié au multithreading. Si un seul et même programme fonctionnant sur des cartes différentes tente d'utiliser la bibliothèque, il peut y avoir une collision avec le fichier de modèle - soit une erreur d'accès, soit deux copies identiques du modèle seront lancées discrètement, bien que des copies différentes aient été utilisées.

Vous devez générer un nom temporaire, de préférence de la forme (c'était __FILE__, "strike" ne fonctionne pas en html ici) MQL-program-name + timestamp + random.

Il est également souhaitable de supprimer les anciens fichiers automatiquement par timeout à chaque appel suivant, par exemple, dans 1 jour (en analysant une partie de l'horodatage), afin qu'ils ne jonchent pas les dossiers.

PS. Le cas est encore pire, car __FILE__ est un fichier source et est toujours égal à Expert.mqh - dans tous les programmes qui l'utilisent ! Correction de la phrase par le nom.
 
Stanislav Korotky:

Cette décision a été prise en toute connaissance de cause, en pesant le pour et le contre.

Il est logique de supprimer un modèle immédiatement après sa création, et non une fois par jour. Toutefois, il est pratique de toujours disposer du dernier modèle sauvegardé pour mieux analyser ce qui se passe.

 
fxsaber:

Il l'a fait délibérément, en pesant le pour et le contre.

Il est logique de supprimer un modèle immédiatement après sa création, et non une fois par jour. Toutefois, il est pratique de toujours disposer du dernier modèle sauvegardé pour mieux analyser ce qui se passe.

Je ne peux citer aucun avantage pour la méthode actuelle. J'ai proposé une méthode plus correcte.

Il est logique de supprimer en une seule fois si Sync = true (ce qui est la valeur par défaut), mais ce n'est pas ce qui est mis en œuvre aujourd'hui - le fichier reste.

 
Stanislav Korotky:

Je ne vois pas un seul "pro" de la méthode actuelle. L'IMHO a suggéré une méthode plus correcte.

Les avantages sont liés à l'application pratique. J'ai lancé Terminal avec des Expert Advisors précédemment lancés, qui au départ se sont immédiatement placés dans leurs modèles. Ils ont fonctionné parfaitement. Je suis sûr qu'il est possible de reproduire la collision théorique. Mais c'est loin d'être une pratique dans mon cas. Si vous décidez de créer une solution universelle, partagez-la ici. Je mettrai à jour la bible. Je ne suis pas prêt à le faire moi-même.

Il est logique d'effacer en une fois si Sync = true (ce qui est le cas par défaut), mais ce n'est pas ce qui est mis en œuvre aujourd'hui - le fichier reste.

Oui, je ne le supprime pas volontairement.

 
fxsaber:

Pour - il s'agit d'une application pratique. J'ai lancé Terminal avec des experts-conseils déjà lancés, qui ont été immédiatement placés dans leurs modèles. Ils ont fonctionné parfaitement. Je suis sûr qu'il est possible de reproduire la collision théorique. Mais c'est loin d'être une pratique dans mon cas. Si vous décidez de créer une solution universelle, partagez-la ici. Je mettrai à jour la bible. Je ne suis pas prêt à le faire moi-même.

Oui, je ne fais pas exprès de l'effacer.

Je ne comprends toujours pas pourquoi le nom de la constante Expert.mqh.tpl est plus "pratique" (pratique ?) que les modèles nommés d'après le programme qui les génère ? Supposons qu'il y ait un programme A.mq5 et un programme B.mq5 utilisant bibla. S'ils généraient des modèles portant leur propre nom, il serait plus pratique, premièrement, d'avoir la dernière "empreinte" des actions de _chaque_ programme, au lieu d'écraser l'un par l'autre. Deuxièmement, il serait possible de voir immédiatement, grâce au nom, qui est le générateur (ce qui est particulièrement pratique si les programmes sont étrangers). Aujourd'hui, il est impossible de le savoir à partir du fichier Expert.mqh.tpl tant que l'on n'y est pas entré. La solution universelle que j'ai donnée est de prendre le nom du programme MQL + horodatage + aléatoire. Et je ne vois pas la nécessité de laisser le fichier à sync=true. Je pense que tout a été testé et débogué depuis longtemps. En cas d'erreurs et de besoin de débogage, il existe une option sync=false. Dans ce cas, le fichier doit être laissé. Je pense que tout est logique. Et les modifications sont simples.

Je suis d'accord que dans la pratique, la collision peut se produire rarement, à moins que quelqu'un n'utilise la biblio en parallèle dans plusieurs programmes. Je ne l'ai pas, mais je viens de jeter un coup d'œil rapide au code, et mon regard a été attiré par Expert.mqh.tpl dans le dossier Files. Tout cela n'est que pure imho.

12345678910111213
Nouveau commentaire