Pourquoi ne pas mettre les paramètres d'entrée dans la structure ?

Nouveau commentaire
 

Je veux dire l'approche de l'EA en classe. Il y a un problème avec le passage des paramètres d'entrée à un EA dont la classe est dans un fichier .mqh séparé. J'utilise deux méthodes

  1. Les paramètres d'entrée sont copiés dans les champs de la classe EA par une ou plusieurs fonctions d'initialisation. C'est l'approche la plus universelle, mais dans le cas d'un grand nombre de variables, c'est celle qui prend le plus de temps.
  2. La classe est définie après les variables d'entrée, elles sont donc visibles depuis l'EA. L'inconvénient - moins de flexibilité lors de l'utilisation de plusieurs instances de la classe. Plus - un minimum d'écriture.

input double LotSize = 0.1;
// другие input переменные...

#include <MyLib\MyClassEA.mqh>
CMyClassEA MyEA;

Et si on fait une extension MQL et qu'on met des variables d'entrée dans la structure ? Il n'est pas compatible avec C++ et C de toute façon, à cause de l'imitation des pointeurs. Alors pourquoi ne pas aller plus loin ?

struct InputVars
{
    input double Lot   = 0.1;
    input int    Magik = 100;
} ivars;

Ensuite, vous pouvez passer la variable ivars à la classe d'algorithme, copier, etc.

Amenez l'idée au niveau du brainstorming ;))

 

Je suis depuis longtemps confronté à la nécessité de travailler avec un grand nombre de paramètres de configuration. Lorsque c'est possible, je résous ce problème en créant une boîte de dialogue spéciale via une DLL dans laquelle les paramètres sont tabulés. Après l'initialisation, cette fenêtre est cachée et le programme fonctionne comme d'habitude.

Si seulement il y avait quelque chose comme ça dans MQL, pour ne pas avoir à parcourir une énorme liste de paramètres. L'idée même de sa mise en œuvre est intéressante. Seule la syntaxe devrait être légèrement différente :

input struct VolumeParams                              // Здесь название вкладки
{
    // Содержимое вкладки
    double Lot1 = 0.01;
    double Lot2 = 0.02;
    double LotRatio = 1.5;
};
 
Ihor Herasko:

Je suis depuis longtemps confronté à la nécessité de travailler avec un grand nombre de paramètres de configuration. Lorsque c'est possible, je résous ce problème en créant une boîte de dialogue spéciale via une DLL dans laquelle les paramètres sont tabulés. Après l'initialisation, cette fenêtre est cachée et le programme fonctionne comme d'habitude.

Si seulement il y avait quelque chose comme ça dans MQL, pour ne pas avoir à parcourir une énorme liste de paramètres. L'idée même de sa mise en œuvre est intéressante. Seule la syntaxe devrait être légèrement différente :


C'est vrai, c'est plus court ) et avec dll ça ne marchera pas dans Market, hélas.

et l'utilisation de la boîte de dialogue ne vous permettra pas d'optimiser les paramètres dans le testeur.

 

alors c'est mieux comme ça :

struct VolumeParams                              
{
    double lot;         //название параметра
    double LotRatio;    //название параметра
    int tp;             //название параметра
    int sl;             //название параметра
    int orders;         //название параметра
};
VolumeParams ParamBuf[5];

input ParamBuf[0];         // Здесь название вкладки
input ParamBuf[1];         // Здесь название вкладки
input ParamBuf[2];         // Здесь название вкладки
input ParamBuf[3];         // Здесь название вкладки
input ParamBuf[4];         // Здесь название вкладки
 

Je pense que c'est une excellente idée, cohérente avec le concept de la POO. Pour l'instant, je vois 2 options :

1) StyleFrameInputs.

parameters

[out] Tableau de chaînes de caractères avec la description des noms et des valeurs des paramètres.

nombre de paramètres

[out] Le nombre d'éléments dans le tableauparameters[].

2) Dans le styleMqlParams.

 

J'utilise toujours la première approche.

Lorsqu'un conseiller expert est placé dans une transaction (que ce soit sur une démo ou sur un compte réel) - les paramètres sont fixes - et un seul paramètre - le pourcentage de risque - est transmis à la classe du conseiller expert. Tous les autres paramètres sont écrits dans la même structure et sont définis à l'intérieur du conseiller expert - soit dans le constructeur, soit dans une fonction spéciale.

 
Alexey Volchanskiy:

Je veux parler de l'approche du "conseiller expert dans une classe". Il y a un problème avec le passage des paramètres d'entrée à l'Expert Advisor dont la classe est située dans un fichier .mqh séparé.

Je ne ressens pas le problème. Prescrire un modèle dans le constructeur de la classe et c'est tout.

 
fxsaber:

Je n'ai pas senti le problème. Vous devez prescrire un modèle dans le constructeur de la classe et c'est tout.


Eh bien, vous n'avez pas communiqué avec les clients)

...ici le client veut 10 entrées, et chaque étape a son propre tp/sl/lot/trall/signal à l'entrée

et que tout cela est optimisé dans le testeur)

 
Taras Slobodyanik:

et bien, vous n'avez pas parlé aux clients)

...donc le client veut 10 entrées, et chaque étape a son propre tp/sl/lot/trall/signal à entrer

et que tout cela est optimisé dans le testeur)

Alors, quel est le rapport avec le sujet de la branche ?

 
fxsaber:

En quoi cela concerne-t-il le sujet du fil de discussion ?


La discussion elle-même s'est en effet légèrement écartée du titre du fil. Maintenant, il s'agit plutôt de la deuxième partie du post de TC :

Alexey Volchanskiy

Et si nous faisions une extension du langage MQL et mettions les variables d'entrée dans la structure ? Il n'est pas compatible avec C++ et C de toute façon, à cause de l'imitation des pointeurs. Alors pourquoi ne pas aller plus loin ?

Ensuite, vous pourriez passer la variable ivars à la classe d'algorithme, copier, etc.

 
fxsaber:

En quoi cela concerne-t-il le sujet du fil de discussion ?


En effet, pour écrire tout ce tas de paramètres, il suffirait de définir la structure et de la mettre dans les paramètres d'entrée.

1234567
Nouveau commentaire