Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Was für ein Blödsinn...
Ich denke auch, dass die Schleifenbildung des EA eine mauvais ton ist. Eine Änderung der Parameter erst nach dem Ende des Startzyklus ist völlig logisch. Der Themenstarter konnte nicht umhin zu verstehen, dass das Problem in seiner Endlosschleife liegt, denn er ist kein Amateur. Allerdings hat er im ersten Beitrag nichts über Endlosschleifen in Expert Advisors geschrieben. Ich persönlich habe solche Systeme in meinen EAs nicht implementiert, aber nach meinen Beiträgen zu urteilen, habe ich verstanden, dass dies vorher nicht passiert ist- das Parameterfenster in EAs mit Schleifen wurde einfach nicht geöffnet. Das bedeutet, dass die Aussage von TC"Es führt zu einer grundsätzlichen Inkompatibilität bestehender EAs mit den neuen Builds von MT4" nicht stimmt - in alten Builds von MT4 war es bei solchen EAs auch nicht möglich, Parameter zu ändern, da es unmöglich war, das Fenster bis zum Ende des Zyklus zu öffnen.
EventSetMillisecondTimer löst das Problem. Doch wie lange ist es her, dass diese Funktion auftauchte? Gab es vorher nicht nur EventSetTimer? Bei einem Mindestaufrufintervall von 1 Sekunde ist ein solches Ereignis völlig nutzlos, wenn man Systeme für den realen Handel schreibt, bei denen es pro Sekunde Dutzende von Ticks für jedes Symbol geben kann.
In derHilfe zu den Zeitschaltuhren gibt es immer noch keinen Hinweis auf diese Funktion! Ich habe sie nur zufällig entdeckt, als Hinweis bei der Eingabe des EventSet.
Es gibt jedoch meiner Meinung nach ein Problem und eine Inkonsistenz im neuen MQL 4/5: Beim Deinitialisieren und Initialisieren gibt es kein Löschen und Neuanlegen von dynamischen Objekten in globalen Variablen...
Es gibt jedoch meiner Meinung nach ein Problem und eine Inkonsistenz im neuen MQL 4/5: Deinitialisierung und Initialisierung entfernen und erstellen keine dynamischen Objekte in globalen Variablen. Das heißt, wenn Parameter des EA in den Konstruktoren von dynamisch erstellten Objekten in globalen Variablen gelesen werden und der EA mit ihnen weiterarbeitet, arbeitet der EA bei einer Änderung der Parameter weiter, als ob sich die Parameter nicht geändert hätten. Meiner Meinung nach ist das nicht logisch, und die globalen Variablen sollten deinitialisiert werden, nachdem der EA deinitialisiert wurde, und dann neu initialisiert werden, bevor der EA initialisiert wird. Dies wird derzeit dadurch gelöst, dass das Initialisieren und Löschen solcher Variablen in OnInit und OnDeinit untergebracht wird
Ja, das ist ein echter Hammer, vor allem wenn man bedenkt, dass in der Dokumentation (wederhier nochhier) nicht hervorgehoben wird, dass das Laden jetzt nicht 1 zu 1 mit dem Initialisierungsereignis verknüpft ist. Hier sind einige Wörter wie diese:
Globale Variablen werden einmal initialisiert, unmittelbar nachdem das Programm in den Speicher des Client-Terminals geladen wurde.
reicht offensichtlich nicht aus, um den Entwickler darauf aufmerksam zu machen, dass nachfolgende Parameteränderungen zwar deinitialisieren und initialisieren, aber KEIN entsprechendes Entladen und Laden durchführen.
Ja, das ist ein echter Hammer, vor allem wenn man bedenkt, dass in der Dokumentation (wederhier nochhier) nicht hervorgehoben wird, dass das Laden jetzt nicht 1 zu 1 mit dem Initialisierungsereignis verknüpft ist. Hier sind einige Wörter wie diese:
Globale Variablen werden einmal initialisiert, unmittelbar nachdem das Programm in den Speicher des Client-Terminals geladen wurde.
reicht offensichtlich nicht aus, um den Entwickler darauf aufmerksam zu machen, dass nachfolgende Parameteränderungen zwar deinitialisieren und initialisieren, aber KEIN entsprechendes Entladen und Laden durchführen.
Es besteht keine Notwendigkeit, die Variablen zu laden/entladen und neu zu initialisieren. Der Programmierer muss sich um die Initialisierung der Variablen kümmern.
Es besteht keine Notwendigkeit, Variablen zu laden/entladen und neu zu initialisieren. Der Programmierer muss sich um die Initialisierung der Variablen kümmern.
Das ist es, was ich meine: Es wird nicht klar gesagt, wann genau diese Initialisierung erfolgt. Code mit einer globalen Variable:
int x = 0;
ist dies auch eine Initialisierung. Aber es ist nicht klar in der Dokumentation geschrieben, dass dies einfach keine Initialisierung aus der Sicht von MC ist.
Streng genommen gibt es jetzt 2 verschiedene Initialisierungen in MT: eine wird beim Programmstart durchgeführt und die andere bei der Änderung der "Umgebung" zum Zeitpunkt des OnInit-Aufrufs. Das Schlimme daran ist, dass sie erst ausgegraben werden müssen.
Beim Starten des Programms wird ein Kaltstart durchgeführt. Den Variablen wird Speicher zugewiesen und sie werden mit Anfangswerten initialisiert.
Im Betrieb - Warmstart. Hier muss sich der Programmierer um die Initialisierung der Variablen kümmern, und das ist gut so.
Beim Starten des Programms wird ein Kaltstart durchgeführt. Den Variablen wird Speicher zugewiesen und sie werden mit Anfangswerten initialisiert.
Im Betrieb - Warmstart. In diesem Fall muss sich der Programmierer um die Initialisierung der Variablen kümmern, und das ist gut so.
Ob das gut oder schlecht ist, ist eine philosophische Frage... Aber die Tatsache, dass es in der Dokumentation 0,0 Informationen darüber gibt, ist nicht gut...
Und wenn ich mich richtig erinnere, gab es so etwas vorher nicht, d.h. es handelt sich, gelinde gesagt, um ein "Feature", das speziell zur "Bequemlichkeit" der Programmierer hinzugefügt wurde, das aber die Invarianz der bestehenden Codes (die für frühere Initialisierungsregeln geschrieben wurden) verletzt. So wird der unumstößliche Grundsatz, die Kompatibilität von altem Code mit neuen Softwareversionen so weit wie möglich zu erhalten, nicht eingehalten.
Niemand hat etwas gegen neue Funktionen und Optimierungen. Aber warum nicht so, dass der alte Code nicht gebrochen wird? Insbesondere könnten wir für eine solche neue Initialisierung einen zusätzlichen Präprozessorbefehl ähnlich #property strict zuweisen. Zum Beispiel #property lazyinit, und wenn es vom Programmierer im Code angegeben wird (d.h. explizit, das heißt, er ist sich der neuen Initialisierung in mql bewusst), dann freuen wir uns über eine optimierte Optimierung. Und wenn es nicht angegeben ist, dann sind wir froh, dass der bisherige Code konsistent funktioniert, ohne dass wir nach Stellen suchen müssen, an denen globale Variablen verbleiben könnten, die jetzt nicht nur deklariert, sondern auch separat in OnInit initialisiert werden müssen. Für jede dieser Variablen gibt es dann 2 Codezeilen statt einer.