Perché non mettere i parametri di input nella struttura?

Nuovo commento
 

Intendo l'approccio EA-in-class. C'è un problema con il passaggio di parametri di input a un EA la cui classe è in un file .mqh separato. Io uso due metodi

  1. I parametri di input sono copiati nei campi della classe EA da una o più funzioni di inizializzazione. Questo è l'approccio più universale, ma nel caso di un gran numero di variabili, è il più lungo.
  2. La classe è definita dopo le variabili di input, quindi sono visibili dall'EA. Lo svantaggio - meno flessibilità quando si usano più istanze della classe. Inoltre - quantità minima di scrittura.

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

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

E se facciamo un'estensione MQL e mettiamo delle variabili di input nella struttura? Non è comunque compatibile con C++ e C, a causa dell'imitazione dei puntatori. Allora perché non andare oltre?

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

Poi si potrebbe passare la variabile ivars alla classe dell'algoritmo, copiare ecc.

Prendi l'idea a livello di brainstorming ))

 

Ho avuto a lungo a che fare con la necessità di lavorare con molti parametri di configurazione. Quando è possibile, risolvo questo problema creando una finestra di dialogo speciale attraverso una DLL in cui i parametri sono a schede. Dopo l'inizializzazione questa finestra viene nascosta e poi il programma viene eseguito come al solito.

Se solo ci fosse qualcosa del genere in MQL, in modo da non dover cercare in un enorme elenco di parametri. L'idea stessa di come implementarla è interessante. Solo la sintassi dovrebbe essere leggermente diversa:

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

Ho avuto a lungo a che fare con la necessità di lavorare con molti parametri di configurazione. Quando è possibile, risolvo questo problema creando una finestra di dialogo speciale attraverso una DLL in cui i parametri sono a schede. Dopo l'inizializzazione questa finestra viene nascosta e poi il programma viene eseguito come al solito.

Se solo ci fosse qualcosa del genere in MQL, in modo da non dover cercare in un enorme elenco di parametri. L'idea stessa di come implementarla è interessante. Solo la sintassi dovrebbe essere leggermente diversa:


Giusto, è più corto ) e con dll non funzionerà in Market, ahimè.

E l'utilizzo della finestra di dialogo non vi permetterà di ottimizzare i parametri nel tester

 

allora è meglio così:

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

Imho, grande idea, coerente con il concetto di OOP. Finora vedo 2 opzioni:

1) StileFrameInputs.

parameters

[out] array di stringhe con la descrizione dei nomi e dei valori dei parametri

numero di parametri

[out] Il numero di elementi nell'arrayparameters[].

2) Nello stileMqlParams.

 

Io uso sempre il primo approccio.

Quando un Expert Advisor viene inserito in un trade (sia su una demo che su un conto reale) - i parametri sono fissi - e solo un parametro - la percentuale di rischio - viene passato alla classe dell'Expert Advisor. Tutti gli altri parametri sono scritti nella stessa struttura e sono definiti all'interno dell'Expert Advisor - o nel costruttore o in una funzione speciale.

 
Alexey Volchanskiy:

Intendo l'approccio "Expert Advisor in una classe". C'è un problema con il passaggio dei parametri di input all'Expert Advisor la cui classe si trova in un file .mqh separato.

Non ha sentito il problema. Prescrivere un modello nel costruttore della classe e questo è tutto.

 
fxsaber:

Non ha sentito il problema. Dovete prescrivere un modello nel costruttore della classe e questo è tutto.


beh, non hai comunicato con i clienti)

...qui il cliente vuole 10 ingressi, e ogni passo ha il suo tp/sl/lot/trall/segnale da inserire

e che tutto questo è ottimizzato nel tester)

 
Taras Slobodyanik:

beh, non hai parlato con i clienti)

...quindi il cliente vuole 10 ingressi, e ogni passo ha il suo tp/sl/lot/trall/segnale da inserire

e che tutto questo è ottimizzato nel tester)

Quindi, come si collega questo all'argomento del ramo?

 
fxsaber:

E questo come si collega all'argomento del thread?


La discussione stessa ha effettivamente deviato leggermente dal titolo del thread. Ora si tratta più della seconda parte del post di TC:

Alexey Volchanskiy

Cosa succede se facciamo un'estensione del linguaggio MQL e mettiamo le variabili di input nella struttura? Non è comunque compatibile con C++ e C, a causa dell'imitazione del puntatore. Allora perché non andare oltre?

Poi si potrebbe passare la variabile ivars alla classe dell'algoritmo, copiare, ecc.

 
fxsaber:

E questo come si collega all'argomento del thread?


Così fa, per scrivere tutto questo mucchio di parametri, basterebbe definire la struttura e metterla nei parametri di ingresso.

1234567
Nuovo commento