¿Por qué no poner los parámetros de entrada en la estructura?

Nuevo comentario
 

Me refiero al enfoque de EA en la clase. Hay un problema al pasar parámetros de entrada a un EA cuya clase está en un archivo .mqh separado. Utilizo dos métodos

  1. Los parámetros de entrada se copian en los campos de la clase EA mediante una o varias funciones de inicialización. Este es el enfoque más universal, pero en caso de un gran número de variables, es el que más tiempo consume.
  2. La clase se define después de las variables de entrada, por lo que son visibles desde el EA. La desventaja - menos flexibilidad cuando se utilizan múltiples instancias de la clase. Además, una cantidad mínima de escritura.

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

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

¿Y si hacemos una extensión MQL y ponemos variables de entrada en la estructura? De todos modos, no es compatible con C++ y C, por la imitación de los punteros. Entonces, ¿por qué no ir más allá?

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

Luego se podría pasar la variable ivars a la clase de algoritmo, copiar, etc.

Lleva la idea a un nivel de brainstorming ))

 

Hace tiempo que tengo que lidiar con la necesidad de trabajar con muchos parámetros de configuración. Siempre que es posible, resuelvo este problema creando un cuadro de diálogo especial a través de una DLL en la que los parámetros están tabulados. Después de la inicialización esta ventana se oculta y entonces el programa se ejecuta como de costumbre.

Ojalá fuera algo así en MQL, para no tener que buscar en una enorme lista de parámetros. La propia idea de cómo aplicarla es interesante. Sólo la sintaxis debe ser ligeramente diferente:

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

Hace tiempo que tengo que lidiar con la necesidad de trabajar con muchos parámetros de configuración. Siempre que es posible, resuelvo este problema creando un cuadro de diálogo especial a través de una DLL en la que los parámetros están tabulados. Después de la inicialización esta ventana se oculta y entonces el programa se ejecuta como de costumbre.

Ojalá fuera algo así en MQL, para no tener que buscar en una enorme lista de parámetros. La propia idea de cómo aplicarla es interesante. Sólo la sintaxis debe ser ligeramente diferente:


Cierto, es más corto ) y con dll no funcionará en Market, por desgracia.

y el uso del cuadro de diálogo no le permitirá optimizar los parámetros en el probador

 

entonces es mejor así:

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];         // Здесь название вкладки
 

En mi opinión, una gran idea, coherente con el concepto de OOP. Hasta ahora veo 2 opciones:

1) EstiloFrameInputs.

parameters

[out] Matriz de cadenas con la descripción de los nombres y valores de los parámetros

conteo_de_parámetros

[out] El número de elementos de la matrizparameters[].

2) En el estiloMqlParams.

 

Siempre utilizo el primer enfoque.

Cuando un Asesor Experto se coloca en una operación (ya sea en una cuenta demo o en una cuenta real) - los parámetros son fijos - y sólo un parámetro - el porcentaje de riesgo - se pasa a la clase del Asesor Experto. Todos los demás parámetros se escriben en la misma estructura y se definen dentro del Asesor Experto, ya sea en el constructor o en una función especial.

 
Alexey Volchanskiy:

Me refiero al enfoque de "Asesor experto en una clase". Hay un problema al pasar los parámetros de entrada al Asesor Experto cuya clase se encuentra en un archivo .mqh separado.

No sentí el problema. Prescribir una plantilla en el constructor de la clase y ya está.

 
fxsaber:

No sentí el problema. Hay que prescribir una plantilla en el constructor de la clase y ya está.


bueno, no te has comunicado con los clientes)

...aquí el cliente quiere 10 entradas, y cada paso tiene su propio tp/sl/lot/trall/señal a introducir

y que todo esto está optimizado en el probador)

 
Taras Slobodyanik:

bueno, no has hablado con los clientes)

...así que el cliente quiere 10 entradas, y cada paso tiene su propio tp/sl/lot/trall/señal a introducir

y que todo esto está optimizado en el probador)

Entonces, ¿cómo se relaciona esto con el tema del ramo?

 
fxsaber:

¿Cómo se relaciona esto con el tema del hilo?


La discusión en sí se ha desviado ligeramente del título del hilo. Ahora se trata más bien de la segunda parte del post de TC:

Alexey Volchanskiy

¿Y si hacemos una extensión del lenguaje MQL y ponemos variables de entrada en la estructura? De todos modos, no es compatible con C++ y C, debido a la imitación de punteros. Entonces, ¿por qué no ir más allá?

Entonces podrías pasar la variable ivars a la clase de algoritmo, copiar, etc.

 
fxsaber:

¿Cómo se relaciona esto con el tema del hilo?


Así es, para escribir todo este montón de parámetros, bastaría con definir la estructura y ponerla en los parámetros de entrada.

1234567
Nuevo comentario