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
Es ist jedoch besser, dies nicht zu tun - alles sollte an seinem Platz sein.
Im EA-Timer nehmen wir eine Liste nach den gewünschten Kriterien und bei list.Total()>xxx tun wir, was wir wollen.
Es stellt sich heraus, dass im alten MQL4, wo es keinen Timer gab, das Problem keine Lösung hatte? Warum sich mit dem Timer abmühen, wenn das Problem in ein paar Zeilen gelöst werden kann?
Das ist genau das, was ich mir angesehen habe.
Und mein Beitrag
Und welchen Sinn hat es im realen Handel, dass wir ständig der Auftragsschleife hinterherlaufen? Vor allem aber ist es Zeitverschwendung...
Um immer aktuelle Informationen über das Handelsumfeld zu haben, müssen Sie nicht jedes Mal suchen, sondern können auf die verfügbaren Listen zurückgreifen. Und da Listen immer aktuell sein sollten, lohnt es sich, darauf zu achten, sie aktuell, aber effizient zu halten.
Wenn Sie keine Listen haben, müssen Sie nach Informationen suchen, wenn Sie sie brauchen. Und das nicht nur einmal pro Tick. Und genau hier zeigen sich die Bremsen, die durch das wiederholte Laden der Umgebung entstehen.
Allerdings ist auch hier eine Optimierung möglich - wenn wir die Kontrolle über Veränderungen in der Umgebung aufgeben und die Listen nur bei Bedarf füllen. Aber dann würden Sie die Möglichkeit verlieren, dass der EA auf die manuellen Schließ-, Änderungs- und Öffnungsaktionen des Benutzers reagiert.
Es stellt sich heraus, dass im alten MQL4, wo es keinen Timer gab, das Problem keine Lösung hatte? Warum sich mit einem Timer abmühen, wenn das Problem in ein paar Zeilen gelöst werden kann?
Wenn das nicht möglich war, mussten wir uns überlegen, wie wir das Problem lösen können. Aber jetzt ist es möglich ;)
Stets aktuelle Informationen über das Handelsumfeld zu haben und bei Bedarf nicht jedes Mal suchen zu müssen, sondern auf bestehende Listen zurückgreifen zu können. Da die Listen immer auf dem neuesten Stand sein sollten, lohnt es sich, darauf zu achten, dass sie stets aktuell, aber effizient sind.
Wenn Sie keine Listen haben, müssen Sie nach Informationen suchen, wenn Sie sie brauchen. Und das nicht nur einmal pro Tick. Und hier werden alle Verlangsamungen bei wiederholtem Laden der Umgebung auftreten.
Aber auch hier kann optimiert werden - wenn Sie sich weigern, Änderungen der Umgebung zu kontrollieren und Listen nur bei Bedarf zu füllen. Aber dann verlieren Sie die Möglichkeit, dass der EA auf Benutzeraktionen zum manuellen Schließen/Ändern/Öffnen reagiert.
Das ist das Schlüsselwort"aber effektiv". Und welchen tieferen Sinn hat es, die Liste jede Millisekunde zu aktualisieren, wenn sich die Liste nur ändern kann, wenn ein weiterer Tick eintrifft? Und warum nicht nur einmal pro Tick? Kann ein Auftrag außerhalb eines Ticks geschlossen werden? So wie ich es sehe, verursacht diese Aktion einen Tick, auch wenn es keinen Tick gibt und der EA einen Befehl zum Öffnen/Schließen sendet, d.h. um die Umgebung, d.h. die Liste, zu ändern. Wenn das nicht der Fall ist, wird die Liste nicht geändert, es sei denn, ein Häkchen wird durch etwas anderes verursacht. Ist es nicht so?
Hier ist das Schlüsselwort"aber effektiv". Und warum ist es so sinnvoll, die Liste jede Millisekunde zu aktualisieren, wenn sie sich nur beim Empfang des nächsten Ticks ändern kann? Und warum nicht nur einmal pro Tick? Kann ein Auftrag außerhalb eines Ticks geschlossen werden? So wie ich es sehe, verursacht diese Aktion einen Tick, auch wenn es keinen Tick gibt und der EA einen Befehl zum Öffnen/Schließen sendet, d.h. um die Umgebung, d.h. die Liste, zu ändern. Wenn das nicht der Fall ist, wird die Liste nicht geändert, es sei denn, ein Häkchen wird durch etwas anderes verursacht. Ist es nicht so?
Im Tester führe ich OnTimer() aus, die Listen nur von OnTick() erstellt, aber im wirklichen Leben machen Sie keinen Unterschied...
Aber nicht nur für die Erstellung von Listen wird ein Timer benötigt. Alles in allem - alles, was wir brauchen, auf einmal. Für den Moment. Eine weitere Profilierung wird die Engpässe aufzeigen.
Das ist das Schlüsselwort"aber effektiv". Und welchen tieferen Sinn hat es, die Liste jede Millisekunde zu aktualisieren, wenn die Liste nur mit dem Eintreffen eines weiteren Ticks geändert werden kann? Und warum nicht nur einmal pro Tick? Kann ein Auftrag außerhalb eines Ticks geschlossen werden? So wie ich es sehe, verursacht diese Aktion einen Tick, auch wenn es keinen Tick gibt und der EA einen Befehl zum Öffnen/Schließen sendet, d.h. um die Umgebung, d.h. die Liste, zu ändern. Wenn das nicht der Fall ist, wird die Liste nicht geändert, es sei denn, ein Häkchen wird durch etwas anderes verursacht. Ist es nicht so?
Wenn das Programm mit vielen Symbolen arbeitet und die Ticks zu unterschiedlichen Zeiten eintreffen, ist es sinnvoll, die Timer zu erzwingen.
Es macht aber keinen Sinn, nicht "Ihre" Auftragsliste zu durchsuchen, sondern die vom Terminal erstellte, was der Grund für die Probleme ist, dass die Liste von jemand anderem geändert wird.
Wenn das Programm mit vielen Symbolen arbeitet und die Ticks zu unterschiedlichen Zeiten eintreffen, ist es sinnvoll, die Timer zu erzwingen.
Es ist jedoch nicht sinnvoll, nicht die eigene Liste der Aufträge zu durchsuchen, sondern die vom Terminal erstellte Liste, was zu Problemen führt, wenn die Liste von jemand anderem geändert wird.
Im Falle der "nicht eigenen" Liste gibt es eine Gesamtanzahl von Aufträgen, die in einer statischen Variablen gespeichert werden kann, und die Schleife kann so ausgeführt werden, dass die Umgebung aufgezählt wird, wenn sie sich ändert. Aber nicht jede Millisekunde...
Für den Fall, dass die Liste "nicht die eigene" ist, kann die Gesamtzahl der Aufträge in einer statischen Variablen gespeichert und eine Schleife ausgeführt werden, um die Umgebung bei Änderungen erneut zu überprüfen. Aber nicht jede Millisekunde...
Sie können die Auslösung eines schwebenden Auftrags auf diese Weise nicht abfangen.
Es gibt keine Möglichkeit, das Auslösen eines schwebenden Auftrags auf diese Weise abzufangen.
Es geht also nicht darum, Flöhe zu fangen, d.h. den ausstehenden Auftrag, sondern darum, alle Aufträge im Millisekundentakt zu testen.
Es geht also nicht darum, Flöhe zu fangen, d.h. ausstehende Aufträge, sondern darum, alle Aufträge im Millisekundentakt durchzugehen.
- Wozu braucht man eine Bratpfanne?
- Zum Beispiel, um Eier zu braten.
- Es geht nicht um Rührei, es geht um die Bratpfanne...