Brauche Hilfe von MT4-Entwicklern und Programmierern - Seite 7

Neuer Kommentar
 

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 in Bezug auf die Initialisierung von Variablen ein Problem und eine Inkonsistenz im neuen MQL 4/5: Bei der Deinitialisierung und Initialisierung werden dynamische Objekte in globalen Variablen nicht gelöscht und neu erstellt. 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
 
AntFX:
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...
Das ist ein guter Punkt... aber anscheinend haben die Entwickler entschieden, dass nur "Geburt" und "Tod" des Programms den Anfangswert der globalen Variablen beeinflussen können... also müssen wir im Deinitialisierungsblock die Werte der globalen Variablen auf Null zurücksetzen oder ihnen die Anfangswerte zuweisen ....
 
AntFX:
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.

 
marketeer:

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.

 
Contender:

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, die beim Laden des Programms durchgeführt wird, und eine, wenn die "Umgebung" beim Aufruf von OnInit geändert wird. Es ist schon schlimm genug, dass dies aufgedeckt werden muss.
 
marketeer:
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.

 
Contender:

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.

Gut oder schlecht, das ist eine philosophische Frage... Aber die Tatsache, dass es in der Dokumentation 0,0 Informationen darüber gibt, ist nicht gut...
 
denkir:
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.

12345678
Neuer Kommentar