Warum werden die Eingabeparameter nicht in die Struktur aufgenommen?

 

Ich meine den EA-in-Class-Ansatz. Es gibt ein Problem bei der Übergabe von Eingabeparametern an einen EA, dessen Klasse sich in einer separaten .mqh-Datei befindet. Ich verwende zwei Methoden

  1. Die Eingabeparameter werden durch eine oder mehrere Initialisierungsfunktionen in die Felder der EA-Klasse kopiert. Dies ist der universellste Ansatz, aber bei einer großen Anzahl von Variablen ist er am zeitaufwendigsten.
  2. Die Klasse wird nach den Eingabevariablen definiert, so dass sie vom EA aus sichtbar sind. Der Nachteil: weniger Flexibilität bei der Verwendung mehrerer Instanzen der Klasse. Plus - minimaler Schreibaufwand.

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

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

Und was, wenn wir eine MQL-Erweiterung erstellen und Eingabevariablen in die Struktur einfügen? Es ist sowieso nicht kompatibel mit C++ und C, wegen der Nachahmung von Zeigern. Warum also nicht weiter gehen?

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

Dann könnte man die Variable ivars an die Algorithmusklasse übergeben, kopieren usw.

Bringen Sie die Idee auf eine Brainstorming-Ebene ))

 

Ich hatte lange Zeit mit der Notwendigkeit zu tun, mit vielen Konfigurationsparametern zu arbeiten. Wann immer es möglich ist, löse ich dieses Problem, indem ich über eine DLL ein spezielles Dialogfeld erstelle, in dem die Parameter mit Registerkarten versehen sind. Nach der Initialisierung wird dieses Fenster ausgeblendet und das Programm läuft dann wie gewohnt.

Wenn es nur so etwas in MQL gäbe, so dass man nicht eine riesige Liste von Parametern durchsuchen müsste. Allein die Idee, wie sie umgesetzt werden kann, ist interessant. Nur die Syntax sollte etwas anders sein:

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

Ich hatte lange Zeit mit der Notwendigkeit zu tun, mit vielen Konfigurationsparametern zu arbeiten. Wann immer es möglich ist, löse ich dieses Problem, indem ich über eine DLL ein spezielles Dialogfeld erstelle, in dem die Parameter mit Registerkarten versehen sind. Nach der Initialisierung wird dieses Fenster ausgeblendet und das Programm läuft dann wie gewohnt.

Wenn es nur so etwas in MQL gäbe, so dass man nicht eine riesige Liste von Parametern durchsuchen müsste. Allein die Idee, wie sie umgesetzt werden kann, ist interessant. Nur die Syntax sollte etwas anders sein:


Richtig, es ist kürzer) und mit dll wird es leider nicht in Market funktionieren.

und bei Verwendung des Dialogfelds können Sie die Parameter im Tester nicht optimieren

 

dann ist es besser so:

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 eine großartige Idee, die mit dem Konzept von OOP übereinstimmt. Bislang sehe ich 2 Möglichkeiten:

1)FrameInputs-Stil.

parameters

[out] String-Array mit der Beschreibung der Parameternamen und -werte

Parameter_Zahl

[out] Die Anzahl der Elemente in dem Arrayparameters[].

2) Im Stil vonMqlParams.

 

Ich wähle immer den ersten Ansatz.

Wenn ein Expert Advisor in einem Handel platziert wird (entweder auf einem Demo- oder auf einem realen Konto) - sind die Parameter festgelegt - und nur ein Parameter - der Risikoprozentsatz - wird an die Klasse des Expert Advisors übergeben. Alle anderen Parameter sind in der gleichen Struktur geschrieben und werden innerhalb des Expert Advisors definiert - entweder im Konstruktor oder in einer speziellen Funktion.

 
Alexey Volchanskiy:

Ich meine den Ansatz des "Expert Advisor in a class". Es gibt ein Problem bei der Übergabe der Eingabeparameter an den Expert Advisor, dessen Klasse sich in einer separaten .mqh-Datei befindet.

Ich habe das Problem nicht gespürt. Eine Vorlage im Klassenkonstruktor vorschreiben und das war's.

 
fxsaber:

Ich habe das Problem nicht gespürt. Sie müssen im Klassenkonstruktor eine Vorlage vorgeben und das war's.


Nun, Sie haben nicht mit Kunden gesprochen)

...hier möchte der Kunde 10 Eingänge, und jeder Schritt hat sein eigenes tp/sl/lot/trall/signal zum Eingang

und dass all dies im Prüfgerät optimiert wird)

 
Taras Slobodyanik:

Nun, Sie haben nicht mit Kunden gesprochen)

...der Kunde möchte also 10 Eingänge, und jeder Schritt hat sein eigenes tp/sl/lot/trall/signal für den Eingang

und dass all dies im Prüfgerät optimiert wird)

Was hat dies nun mit dem Thema der Branche zu tun?

 
fxsaber:

Was hat dies mit dem Thema des Threads zu tun?


Die Diskussion selbst ist in der Tat etwas vom Titel des Themas abgewichen. Jetzt geht es eher um den zweiten Teil von TCs Beitrag:

Alexey Volchanskiy

Was wäre, wenn wir eine Erweiterung der MQL-Sprache vornehmen und Eingabevariablen in die Struktur einfügen? Es ist sowieso nicht kompatibel mit C++ und C, wegen der Zeiger-Imitation. Warum also nicht weiter gehen?

Dann könnte man die Variable ivars an die Algorithmusklasse übergeben, kopieren usw.

 
fxsaber:

Was hat das nun mit dem Thema des Threads zu tun?


Um diesen ganzen Haufen von Parametern zu schreiben, würde es reichen, die Struktur zu definieren und sie in die Eingabeparameter zu setzen.

Grund der Beschwerde: