Fehler, Irrtümer, Fragen - Seite 492

 
komposter:

Auf jeden Fall, und zwar auf allen von ihnen.

Danke für den Hinweis. Ich habe OnTimer() völlig vergessen. Ich habe es durchgezogen und bin zufrieden)
 
Rosh:
So viel wie verfügbar war, so viel wurde auch empfangen. So muss man das verstehen. Prüfen Sie die verfügbare Tiefe der Historie. Stellen Sie sicher, dass die Daten verfügbar sind, bevor Sie sie anfordern. Welches Build haben Sie? Kürzlich wurde ein Fehler beim Kopieren von monatlichen Zeitrahmen behoben, vielleicht ist es das.
In welchem Build sollte es eine Korrektur geben? Es gibt einen Fehler in 489.
 
marketeer:
Das bedeutet, dass wir es schlecht überprüft haben oder dass der EA NICHT mehrwährungsfähig ist, sondern nur für verschiedene Symbole funktioniert. Der Grund dafür ist einfach: Sie wissen, dass die Zecken zu unterschiedlichen Zeiten auf verschiedene Symbole kommen. Wenn ein EA z. B. onTick EURUSD ist und GBPUSD oder auch nur Tick-Änderungen von GBPUSD anstelle von EURUSD prüft, wird das Ergebnis anders ausfallen. Insbesondere kann ein auf EURUSD gebildeter Balken vor der Bildung eines Balkens mit der gleichen Zeit auf GBPUSD auftreten. Wenn Sie GBPUSD zweimal auf demselben Balken handeln: Der vorherige GBPUSD-Balken wird weiterhin als neuer Balken (Null) betrachtet. Was die Mehrwährungsindikatoren betrifft, ist alles klar. Lernen Sie die Grundlagen.

Was zum Teufel ist die Mathematik, ein Tick hat auf 1 Paar kommen, aber wenn der zweite Tick ist spät und f...

d.h. wir benötigen den Preis zum Zeitpunkt des Erscheinens eines neuen Balkens und die Ticks

Es spielt nicht bei allen Symbolen eine Rolle beim Auftreten eines neuen Balkens, aber es ist von

Die Strategie hängt davon ab, ob Sie ein Scalper sind oder nicht

 

Ich möchte das MQ-Team noch einmal fragen, ob es Pläne gibt, die Funktion iCustom() in einen funktionierenden Zustand zu bringen.

Derzeit können die Entwickler von Expert Advisor keine universelle Lösung mit iCustom() anbieten,

wo der Kunde den Namen eines externen Indikators angeben kann, der vom Expert Advisor verwendet wird.

Zu diesem Zweck benötigt der Kunde den Quellcode des Expert Advisors sowie die manuelle Eingabe jedes Indikatornamens in den Code des Expert Advisors, was, gelinde gesagt, ziemlich umständlich ist.

Es gibt auch das Problem der obligatorischen expliziten Angabe der Werte der Indikatorpufferzellen.

Wenn den Zellen des Indikatorpuffers im Indikatortext kein Wert (leer oder nicht leer) explizit zugewiesen wird, kann die Funktion iCustom() die angegebenen Zellen im Expert Advisor mit

mit irgendwelchen Abfällen. Ich denke, dass eine solche Funktionsweise nicht als korrekt angesehen werden kann.

 
MoneyJinn:

Ich möchte das MQ-Team noch einmal fragen, ob es Pläne gibt, die Funktion iCustom() in einen funktionierenden Zustand zu bringen.

Derzeit können die Entwickler von Expert Advisor keine universelle Lösung mit iCustom() anbieten,

wo der Kunde den Namen eines externen Indikators angeben kann, der vom Expert Advisor verwendet wird.

Dazu benötigt der Kunde den Quellcode des Expert Advisors sowie die manuelle Eingabe jedes Indikatornamens in den Code des Expert Advisors, was, gelinde gesagt, ziemlich umständlich ist.

Sie können einen dynamischen Namen des aufgerufenen Indikators in iCustom übergeben, aber der Parametersatz jedes benutzerdefinierten Indikators ist anders.

Leider kennen wir keine allgemeingültige Lösung für die Frage "Wie können wir den Aufruf sicher implementieren, ohne den Code zu berühren, ohne zu wissen, was und mit welchen Parametern er aufgerufen wird?

Wenn ich es richtig verstehe, möchten Sie ein Plugin-System einrichten, wenn ein Drittnutzer einen beliebigen Namen des Indikators mit Parametern (z. B. "MyIndicator(10,20,50,100)") in den EA-Einstellungen festlegt. Für einen solchen Fall mit einem starren Format des Namens können Sie die Zeichenkette selbst parsen, einen Block von Parametern bilden und einen dynamischen Aufruf von iCustom mit einem anderen Satz von Parametern als Wrapper-Klasse implementieren. Mit anderen Worten, es werden mehrere Varianten des iCustom-Aufrufs mit unterschiedlichen Mengen/Anzahl von Parametern darin versteckt.


Ein weiteres Problem ist die obligatorische ausdrückliche Angabe des Wertes der Indikatorpufferzellen.

Wenn der Indikatorpufferzelle im Indikatortext kein Wert (leer oder nicht leer) explizit zugewiesen wird, kann die Funktion iCustom() die angegebenen Zellen im Expert Advisor mit

mit irgendwelchen Abfällen. Ich denke, dass eine solche Funktionsweise nicht als korrekt angesehen werden kann.

Es ist eine Unverschämtheit und geradezu Faulheit des Bauherrn, den ihm zur Verfügung stehenden Puffer nicht auszufüllen.

Das Laufzeitsystem weiß nicht, wie Sie den Indikatorpuffer verwenden, und hat kein Recht, ihn mit einigen Werten zu füllen, insbesondere in den Momenten, in denen es zu Massenüberlastungen kommt (Paging oder Chart-Updates). Der Indikator wird notwendigerweise über alle Fälle benachrichtigt, in denen eine Neuberechnung über die Funktion OnCalculate(...,const int prev_calculated,...) und den Parameter prev_calculated erforderlich ist.

 
Renat:

In iCustom können Sie einen dynamischen Namen des aufzurufenden Indikators übergeben, aber jeder benutzerdefinierte Indikator hat seinen eigenen Satz von Parametern.

Leider kennen wir keine allgemeingültige Lösung für die Frage "Wie können wir den Aufruf sicher implementieren, ohne den Code zu stören, da wir nicht wissen, was und mit welchen Parametern er aufgerufen wird?

Wenn ich es richtig verstehe, möchten Sie ein Plugin-System einrichten, wenn ein Drittnutzer einen beliebigen Namen des Indikators mit Parametern (z. B. "MyIndicator(10,20,50,100)") in den EA-Einstellungen festlegt. Für einen solchen Fall mit einem starren Format des Namens können Sie die Zeichenkette selbst parsen, einen Block von Parametern bilden und einen dynamischen Aufruf von iCustom mit einem anderen Satz von Parametern als Wrapper-Klasse implementieren. Mit anderen Worten, es werden mehrere Varianten des iCustom-Aufrufs mit unterschiedlichen Mengen/Anzahl von Parametern darin versteckt.

Mit der problematischen Notwendigkeit, den Code zu ändern, meinte ich das Erfordernis, den Indikatornamen beim Testen explizit anzugeben

im Format #property tester_indicator "Name.ex5", aber nicht eine andere Anzahl von Parametern des Indikators.

Die Indikatoren können mit den Standardparametern verwendet werden, indem nur die Anzahl der Indikatorpuffer mit dem entsprechenden Signal ausgewählt wird.

Renat:

Es ist eine Unverschämtheit und pure Faulheit des Bauherrn, den ihm zur Verfügung stehenden Puffer nicht auszufüllen.

Das Laufzeitsystem weiß nicht, wie Sie den Indikatorpuffer verwenden, und hat kein Recht, ihn mit einigen Werten zu füllen, insbesondere in den Momenten, in denen es zu Massenüberlastungen kommt (Paging oder Chart-Updates). Über die Funktion OnCalculate(...,const int prev_calculated,...) und den Parameter prev_calculated wird der Indikator zwingend über alle Fälle der Notwendigkeit einer Neuberechnung informiert.

Ist es wirklich so schwer, unbenutzten Zellen in iCustom() Empty_Value zuzuweisen, anstatt sie mit Müll vom Stapel zu verstopfen?

https://www.mql5.com/ru/forum/1111/72233#comment_72233

Beachten Sie, dass der aktuelle Wert der Pufferzellen ein Leerwert bleibt. Es ist iCustom(), das die Manipulationen vornimmt.

 
MoneyJinn:

Mit der problematischen Notwendigkeit von Änderungen im Code meinte ich die Anforderung, den Indikatornamen beim Testen explizit anzugeben

im Format #property tester_indicator "Name.ex5", aber nicht eine andere Anzahl von Parametern des Indikators.

Wir werden das Problem weiter lösen - es gibt Nuancen.

Ist es wirklich schwierig, unbenutzten Zellen in iCustom() den Wert Empty_Value zuzuweisen, anstatt sie mit Müll vom Stapel zu füllen?

https://www.mql5.com/ru/forum/1111/72233#comment_72233

Dies ist nicht möglich. Bitte lesen Sie meine Antwort noch einmal.
 
Renat:

Dies sollte nicht getan werden. Lesen Sie bitte noch einmal meine Antwort.

Der Grund, warum iCustom() den Pufferzellen, die eigentlich nicht gefüllt sind, beliebige Werte zuweist, ist mir unklar, und ich verstehe auch nicht, warum dies nicht irgendwie vermieden werden kann.

Ich vermute, es hat etwas mit der Zuweisung von Speicher für das entsprechende Datenfeld des Indikatorpuffers zu tun.

Eine solche Operation von iCustom(), bei der es unmöglich ist, die Herkunft und den Wahrheitsgehalt der Daten festzustellen, erscheint mir unzulässig und schafft zusätzliche Risiken für den Nutzer.

Wenn iCustom() den Pufferzellen willkürliche, nicht mit den realen Werten übereinstimmende Werte zuweist,

Warum wird diesen Zellen nicht der Wert "Empty_Value" zugewiesen, wie es in MT4 implementiert ist?

Dann wäre zumindest ihr Status klar.

 
Ich widerspreche nicht.
kPeriod2 = kPeriod1 * nextPriod;

Warning : possible loss of data due to type conversion
aber auf diese Weise
kPeriod2 = round(kPeriod1 * nextPriod - 0.5);

Warning : possible loss of data due to type conversion 
wird aufgerundet, steht das noch da?
 
Lodar:
Ich widerspreche nicht.
aber auf diese Weise
es wird noch gerundet geschrieben, sollte das so sein?


Prüfen Sie, ob alle Ihre Variablen vom gleichen Typ sind. Und dann ist da noch der Abschnitt über dieTypenumwandlung. Die Warnung wird durch eine implizite Typumwandlung verursacht, die zur Kompilierzeit erkannt wird.
Документация по MQL5: Основы языка / Типы данных / Приведение типов
Документация по MQL5: Основы языка / Типы данных / Приведение типов
  • www.mql5.com
Основы языка / Типы данных / Приведение типов - Документация по MQL5
Grund der Beschwerde: