Das Problem der Umstellung von MT4 auf MT5. Oder, genauer gesagt, die Unfähigkeit, einige Algorithmen in MT5 ohne Fehler auszuführen. - Seite 7
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
Der Unsinn besteht darin, eine eigene Kopie der Daten zu organisieren, die bereits im Terminal vorhanden sind.
Es gibt eine Menge solchen Unsinns. Als MT4 im August 2005 veröffentlicht wurde, erschien der ZigZag-Indikator. Hier gibt es eine Menge Fehler. In einem Fall könnte es das Terminal auf dem schnellen Markt zu dieser Zeit hängen. Und es zeigte oft Extrema in der Luft an, die nicht mit den Minima/Maxima der Balken zusammenhingen.
In einem Beitrag sagte der Entwickler dieses Zickzacks, dass dies - (bitte keine Emotionen zeigen) eine Manifestation der unscharfen Logik ist ........
Aber bis jetzt, 14 Jahre sind seit der Einführung von MT4 vergangen, gibt es im Zickzack-Indikator einen Parameter - Deviation - der keine Aktion erzeugt. Das bedeutet, dass sich die Zickzack-Zeichnung auf dem Diagramm nicht ändert, egal welchen Wert Sie für diesen Parameter einstellen.
Eine Vielzahl von Programmen basiert auf diesem Indikator. Die meisten Entwickler nehmen diesen Parameter in ihre Programme auf. Es ist ein nutzloser Parameter. Die Entwickler zeigen eine fantastische Gleichgültigkeit gegenüber diesem Thema. Dieser Parameter verschlingt übrigens Computerressourcen.
Es gab viele solcher Momente bei verschiedenen anderen Gelegenheiten.
Ich werde fortfahren.
Diese in der Luft hängenden Zickzack-Extreme sind genau von der gleichen Art wie die, die wir beim Zugriff auf die Zeitreihen haben.
Es ist nur so, dass der Zugang zu Zeitreihen in MT4 nicht verweigert wurde. Einige Funktionen funktionierten dort nicht richtig (vielleicht tun sie es jetzt noch). Ich hatte eine Erklärung für meinen eigenen internen Gebrauch. Ich habe auch selbst einen erzwungenen Versuch unternommen. Und alles funktionierte ohne Fehler und ohne CPU-Last. Selbst die Ausgabe von mehreren Dutzend Zickzacklinien auf Diagrammen führte nicht zum Aufhängen des Terminals...
Wenn alles funktionieren würde, gäbe es nicht eine Million Themen, die sich mit diesem Problem befassen.
Die Logik hat sich einfach als komplizierter herausgestellt, als die Terminalbenutzer bereit sind, damit umzugehen.
Und es muss Fehler geben, aber die Entwickler haben keine Zeit, sie zu suchen, und niemand will sie reproduzieren und bei den Nutzern nachweisen.
Andrei, ich schlage vor, wir beginnen mit dem, was wir haben. Und da wir das haben, wovon Sie sprechen, ist es besser, darüber zu sprechen oder es zu vermeiden?
Ich denke, es gibt genug Probleme, aber anstatt über sie von Zweig zu Zweig zu reden (was auch nützlich ist - manchmal werden sie behoben), sondern die Abhilfe zu tun.
Und ich habe eine gute Option vorgeschlagen - die notwendigen Zeitreihen zum Zeitpunkt ihrer vollständigen Verfügbarkeit zwischenzuspeichern. Und dann - holen Sie sich alle notwendigen Daten aus fertigen und immer verfügbaren Zeitreihen. Und ergänzen sie nur mit neuen Daten. Wenn sie verfügbar sind - langsam und nicht unbedingt in dem Moment, in dem Sie sie brauchen.
Auf diese Weise kommen die Dinge wenigstens voran. Und die Gespräche können auf später verschoben werden - wenn es nichts zu tun gibt.
Ich werde fortfahren.
Diese in der Luft hängenden Zickzack-Extreme sind genau von der gleichen Art wie die, die wir beim Zugriff auf die Zeitreihen haben.
Es ist nur so, dass der Zugang zu Zeitreihen in MT4 nicht verweigert wurde. Einige Funktionen funktionierten dort nicht richtig (vielleicht tun sie es jetzt noch). Ich hatte eine Erklärung für meinen eigenen internen Gebrauch. Ich habe auch selbst einen erzwungenen Versuch unternommen. Und alles funktionierte ohne Fehler und ohne CPU-Last. Selbst die Ausgabe von mehreren Dutzend Zickzacklinien in die Diagramme führte nicht zum Aufhängen des Terminals...
Wenn der Zugriff auf die Zeitreihe verweigert wird, bedeutet dies, dass sie sich in der Synchronisierungsphase befindet. Sie müssen bis zum nächsten Ticken warten.
In Ihrer Situation ist es besser, die Zeitreihen im Cache zu speichern - dann sind sie immer verfügbar, ohne dass Sie warten müssen, und zwar bei der ersten Anfrage.
Zwischenspeichern, wenn der Indikator startet - wenn Zeit zum "Warten auf die Synchronisierung" ist und während des Wartens auf die Anforderung von Daten für die nächste Zeitreihe.
Andrei, ich schlage vor, dass wir mit dem arbeiten, was wir haben. Und da wir haben, wovon Sie sprechen, ist es besser, darüber zu sprechen oder es zu umgehen?
Ich denke, es gibt genug Probleme, aber anstatt von Zweig zu Zweig darüber zu reden (was auch nützlich ist - manchmal werden sie behoben), sollte man lieber den Workaround machen.
Und ich habe eine gute Option vorgeschlagen - die benötigten Zeitreihen zum Zeitpunkt ihrer vollständigen Verfügbarkeit zwischenzuspeichern. Und weiter - um alle benötigten Daten aus fertigen und immer verfügbaren Zeitreihen zu erhalten. Und ergänzen sie nur mit neuen Daten. Und zwar dann, wenn sie verfügbar sind - nicht übereilt und nicht unbedingt in dem Moment, in dem sie gebraucht werden.
Auf diese Weise kommen die Dinge wenigstens voran. Und Gespräche können auf später verschoben werden - wenn es nichts zu tun gibt.
Dann ist es schon effektiver, ein reproduzierbares Beispiel zu machen, das die Entwickler beheben können.
Andrei, ich schlage vor, dass wir mit dem arbeiten, was wir haben. Und da wir haben, wovon Sie sprechen, ist es besser, darüber zu sprechen oder es zu umgehen?
Ich denke, es gibt genug Probleme, aber anstatt über sie von Zweig zu Zweig zu reden (was auch nützlich ist - manchmal werden sie behoben), sollten Sie die Umgehung durchführen.
Und ich habe eine gute Option vorgeschlagen - die notwendigen Zeitreihen zum Zeitpunkt ihrer vollständigen Verfügbarkeit zwischenzuspeichern. Und dann, um alle benötigten Daten aus fertigen und immer verfügbaren Zeitreihen zu erhalten. Und ergänzen sie nur mit neuen Daten. Und zwar dann, wenn sie verfügbar sind - nicht übereilt und nicht unbedingt in dem Moment, in dem sie gebraucht werden.
Auf diese Weise kommen die Dinge wenigstens voran. Und Gespräche können auf später verschoben werden - wenn es nichts zu tun gibt.
Und warum können die Entwickler des Terminals das nicht tun? Zum Zeitpunkt der Aktualisierung gibt es ohnehin keinen Zugang zu den Zeitreihen. Jeder soll Zugang zu diesem, sagen wir mal, zwischengespeicherten Verlauf haben. Welchen Unterschied würde das machen? Das heißt, dass es nie zu einer Unterbrechung des Zugangs kommen würde. Nun, vielleicht gäbe es einige Verzögerungen bei der Nullbar. Der Rest der Geschichte würde immer verfügbar sein.
Ich habe eine gute Option vorgeschlagen - die benötigte Zeitreihe zum Zeitpunkt ihrer vollständigen Verfügbarkeit zwischenzuspeichern. Und dann alle notwendigen Daten aus fertigen und stets verfügbaren Zeitreihen zu erhalten. Und ergänzen sie nur mit neuen Daten.
Das ist eine schlechte Variante, man muss die Logik des Aufbaus und der Synchronisation der Zeitreihen im Terminal komplett wiederholen - ein neuer Tick kam, die Synchronisation war noch nicht beendet... dann ein Verbindungsfehler
ZS: Ja, und warum tun Sie das? - Ich weiß nicht, wie viele im Leben, ich habe ein Handy, ein Auto, und sogar eine Brieftasche mit nur einem, aber eine Menge von Fällen im Leben? - Brauchen Sie eine Versicherung? .... "Drei Kassettenrekorder, drei ausländische Filmkameras, drei Zigarettenetuis für den Hausgebrauch, Jacke... Wildleder... Drei. Jacken" )))
Wenn der Zugriff auf die Zeitreihe verweigert wird, bedeutet dies, dass sie synchronisiert ist. Sie müssen bis zum nächsten Ticken warten.
Sie haben Recht! Aber es ist notwendig, das MQL-Programm an einer beliebigen Stelle zu stoppen und das Terminal bis zum nächsten Tick zu beenden... Ich schlage regelmäßig etwas wie in Delphi "Abort() oder Halt()" vor - erhalten Sie einen Zeitreihenzugriffsfehler einmal - es istein kritischer Fehler, der keinen Sinn macht, viele Male zu behandeln - es wird nicht funktionieren, bis das Terminal die Kommunikation mit dem MQL-Programm sowieso )))
SZZ: Ich schaffe nicht diesen Fehler (Zeitreihenzugriffsfehler) - es wird von Terminal erstellt, aber alle MQL-Programmierer sollten bereit sein, Terminal-generierte Fehler zu debuggen... (wenn der Code aus ein paar hundert Zeilen besteht) ist es einfach, damit zu spielen, aber wenn der Code groß ist und es ist bequem, Zeitreihenzugriff von verschiedenen Programmabschnitten zu verwenden - und es erfordert 999 Möglichkeiten, um von jedem Abschnitt zu verlassen und nicht zu verlieren vorherige Berechnungen? - Ja, das ist möglich, aber es erfordert einen klaren Plan (Algorithmus), nach dem der Quellcode geschrieben wird ... Und wenn der Quellcode durch Hinzufügen vorgefertigter Funktionen (Klassen) verfeinert wird? - d.h. du musst jedes Mal herausfinden, was drin ist... eine generell zeitaufwändige Aufgabe für große Projekte, um alles bereitzustellen, imho
Wenn ein Programm seit 14 Jahren entwickelt wurde, ist es einfacher, es mit der neuen Entwurfsmethode zu übersetzen, als sich selbst ins Unrecht zu setzen. Und auch die Fehlersuche bei Mehrfachverknüpfungen ist schwierig. Die Überprüfung der Zugänglichkeit zu den Zeitplänen führt zu erheblichen Verzögerungen, wenn kein Zugang vorhanden ist. Es wäre gut, wenn automatischegrafische Konstruktionen aktiviert wären. Die Wiederherstellung im automatischen Modus ist ein seltenes Phänomen. Möglicherweise bemerken Sie hier nicht einmal Verzögerungen. Aber auch in diesem Fall, wenn der Zugriff auf Zeitreihen unterbrochen wird, werden die grafischen Konstruktionen manchmal in abgeschnittener Form ausgegeben. Einige der Elemente haben Zeit, gebaut zu werden, andere nicht... Oder die fraktale Filtration schneidet einige tf ab.
***
Wenn ein Programm 14 Jahre lang entwickelt wurde, ist es einfacher, es mit einer neuen Entwurfsmethode zu übersetzen, als sich selbst ins Unrecht zu setzen. Und auch die Fehlersuche bei Mehrfachverknüpfungen ist schwierig. Die Überprüfung der Zugänglichkeit zu den Zeitplänen führt zu erheblichen Verzögerungen, wenn kein Zugang vorhanden ist. Es wäre gut, wenn automatische grafische Konstruktionen aktiviert wären. Die Wiederherstellung im automatischen Modus ist ein seltenes Phänomen. Möglicherweise bemerken Sie hier nicht einmal Verzögerungen.
Problematisch wird es jedoch, wenn die Anpassung über eine grafische Schnittstelle erfolgt. Der Benutzer drückt die Taste und... muss auf den nächsten Tick warten. Oder der Benutzer drückt die Taste mehrmals, bis die gewünschte Reaktion erfolgt. Was ist die Reaktion der Benutzer? -***
In MT4 gibt es solche Probleme nicht.
Ich verstehe Sie sehr gut, deshalb habe ich beschlossen, die Diskussion zu unterstützen
iClose()...iXXX() Funktionen für den Zugriff auf Zeitreihen - großartig!
Es können synchrone Funktionen sein, d.h. der Zugriff auf die Zeitreihen wird länger dauern, aber auf der Terminalebene garantiert sein. Oder die U.V.-Entwickler sollten eine Precompiler-Direktive hinzufügen, die dem MQL-Programm nur dann einen Tick gibt, wenn das Terminal bereit ist, auf historische Daten zuzugreifen (OHLC) - andernfalls kein Tick.
....
aber der einzige Zweck ist, die endlosen OHLC-Chart-Bereitschaftsprüfungen loszuwerden, dieses Problem wurde seit dem Erscheinen von MT5 nur auf der Ebene der Prüfungen innerhalb des MQL-Programms gelöst, es ist ein zeitraubender Prozess und meiner Meinung nach erwarten die Benutzer, dass das Terminal die Zeitreihendaten ohne Probleme und garantiert zu jeder Zeit, in jedem Codeabschnitt erhält
dies ist eine schlechte Option, Sie müssen die Logik des Aufbaus und der Synchronisierung von Zeitreihen im Terminal komplett wiederholen - dann kam ein neuer Tick, dann wurde die Synchronisierung nicht beendet... dann ein Verbindungsfehler
ZS: Ja, und warum tun Sie das? - Ich weiß nicht, wie viele im Leben, ich habe ein Handy, ein Auto, und sogar eine Brieftasche mit nur einem, aber eine Menge von Fällen im Leben? - Brauchen Sie eine Versicherung? .... "Drei Kassettenrekorder, drei ausländische Filmkameras, drei Zigarettenetuis für den Hausgebrauch, Jacke... Wildleder... Drei. Jacken" )))
Aber das MQL-Programm muss die Berechnungen an irgendeiner Stelle stoppen und das Terminal bis zum nächsten Tick verlassen... Ich schlage gelegentlich so etwas wie in Delphi "Abort() oder Halt()" vor - Sie haben einen Fehler beim Zugriff auf die Zeitreihe - es ist ein kritischer Fehler, der keinen Sinn macht, viele Male zu verarbeiten - jedenfalls, bis das Terminal die Interaktion mit dem MQL-Programm herstellt "es ist sinnlos" ))).
SZZ: Ich schaffe nicht diesen Fehler (Zeitreihenzugriffsfehler) - es wird von Terminal erstellt, aber alle MQL-Programmierer sollten bereit sein, Terminal-generierte Fehler zu debuggen... (wenn der Code aus ein paar hundert Zeilen besteht) ist es einfach, damit zu spielen, aber wenn der Code groß ist und es ist bequem, Zeitreihenzugriff von verschiedenen Programmabschnitten zu verwenden - und es erfordert 999 Möglichkeiten, um von jedem Abschnitt zu verlassen und nicht zu verlieren vorherige Berechnungen? - Ja, das ist möglich, aber es erfordert einen klaren Plan (Algorithmus), nach dem der Quellcode geschrieben wird ... Und wenn der Quellcode durch Hinzufügen vorgefertigter Funktionen (Klassen) verfeinert wird? - d.h. du musst jedes Mal herausfinden, was drin ist... ... zeitraubende Aufgabe für große Projekte, imho
Wenn das Programm durch einen Mausklick ausgeführt wird, spielt es keine Rolle, ob es einen Zugang gibt oder nicht - Sie müssen reagieren. Man kann viel darüber schreiben, wie schlecht alles gemacht ist, aber in diesem Fall ist es besser, einen eigenen Cache zu haben, auf den man bei Bedarf jederzeit zugreifen kann.
Stellen Sie sich das Programm vor, das, anstatt per Mausklick etwas auf die lange berechneten historischen Daten zu geben, sagt - geh eine rauchen - ich hole die aktuellen Daten, die Sie jetzt nicht brauchen, und baue die Zeitreihe neu auf...
Wenn Sie mit dem auskommen müssen, was Sie haben, ist es auf jeden Fall besser, den Cache zu leeren und ihn nach der Freigabe des Zeitserienzugriffs neu aufzubauen.