Servicedesk: Faulheit, Autismus oder mangelnde Bereitschaft, Fehler zuzugeben? Ergänzung der Diagramme durch nicht-native Kerzen.
Ist das die Frage, die Sie vor einem Monat gestellt haben? https://www.mql5.com/ru/forum/1111/page878#comment_344461
FiftyStars:
...Die Geschichte ist, was sie ist. Wir haben keine detaillierte Geschichte. Der Einfachheit halber wird der tiefere Verlauf durch tägliche Balken dargestellt.
Wenn es für Sie unpraktisch ist, schränken Sie die Verwendung dieses Verlaufs manuell ein .
Der Kern der Antwort war damals bereits bekannt(https://www.mql5.com/ru/forum/1111/page878#comment_344518):
Aber ich fürchte, dass sie (die Antwort) in etwa so lauten wird: "Der Programmierer kann selbst das Grenzdatum berechnen und die Tiefe der angeforderten Historie begrenzen.
Ich habe mich mit dem Service Desk in Verbindung gesetzt, weil ich ein Problem damit hatte, Kerzen mit höheren TFs an Charts mit niedrigeren TFs anzuhängen, wenn es keine Historie für niedrigere TFs gibt. Das heißt, wenn wir im M1-Chart an den Anfang der Geschichte gehen, sehen wir die Kerzen nicht ab M1, sondern ab D1 oder sogar ab W1. Aufgrund dieses Beitritts liefert die Funktion SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) nicht das Datum, an dem die M1-Historie endet, sondern das Datum des ersten Balkens außerhalb des Zeitrahmens, d. h. der angegebene Zeitrahmen hat keinen Einfluss auf das Ergebnis.
...
SERIES_BARS_COUNT liefert die Anzahl der Kerzen (Balken), die zu einem bestimmten Symbol und Zeitrahmen gehören
SERIES_FIRSTDATE liefert das Datum der ersten geöffneten Kerze (Bar), die zu einem bestimmten Symbol und Zeitrahmen gehört.
Mehr Infos
...
Die Funktionen arbeiten korrekt.
Was Sie sehen, ist eine Folge Ihrer vorherigen Qualitätsabfrage.
Die Geschichte ist, was sie ist. Wir haben keine tiefgründige Geschichte. Der Einfachheit halber wird der tiefere Verlauf durch tägliche Balken dargestellt.
Wenn es für Sie unpraktisch ist, schränken Sie die Verwendung dieses Verlaufs manuell ein.
Das ist eine Ausrede, der Programmierer kann nicht alle Möglichkeiten des Beißens der Geschichte vorhersehen, also kann er die Funktion der Suche nach dem ersten Datum der TF nicht vorschreiben. Heute sind sie so, und morgen werden sie neue Wendungen haben, und ohne MQs Wissen wird zum Beispiel der Handel etwas vermasseln.
Und warum brauchen wir das, wenn es eine Standardfunktion gibt, aber die Tatsache, dass sie das Wetter von vorgestern anzeigt, ist schon ein echter Fehler.
Hier liegt der Knackpunkt des Problems für den Programmierer:
Wir müssen nach Varianten der Kriterien suchen, nach denen dieser Balken als erster Balken der ausgewählten TF und alle vorherigen als Zusatz der älteren TF betrachtet werden können. Es kann Lücken in den Takten geben, wie z. B. ein verpasster Takt (dies ist eine direkte Folge des von MQ gewählten Taktaufzeichnungsformats) oder Lücken in den Takten, wie z. B. Wochenende/Feiertag. Und in einer solchen Kakophonie von Zeichen ist es unklar, wie man feststellen kann, dass diese Bar die richtige ist.
Was ist der Kern des Problems für MQ: (wenn wir meinen, dass sie es lösen werden)
Wenn die Geschichte genäht wird, um eine Datei zu verschlüsseln Daten über die Punkte der Naht (es gibt nicht viele, ein Maximum von 21 durch die Anzahl der TF, in der Praxis gibt es 2-3), ist das Problem gelöst. Als Nächstes schreiben Sie eine Funktion, die diese geschützten Informationen liest und sie per Anfrage an den Benutzer ausgibt.
Danke, entscheiden Sie sich nicht für die Händler.
Welcher frische Kopf war es, der nach dem Freitag eine solche Bewegung machte - um die älteren Balken in den M1-Zeitrahmen einzufügen ?
Wer hat Ihnen überhaupt das Recht gegeben, jahrelang bewährte Grundsätze umzukehren?
Wenn Sie sich damit nicht wohlfühlen, schränken Sie die Verwendung dieser Geschichte manuell ein.
Danke, entscheiden Sie sich nicht für die Händler.
Was für ein frischer Kopf war es, nach dem Freitag einen solchen Schritt zu machen - um ältere Balken in den M1-Zeitrahmen einzufügen ?
Wer hat Ihnen das Recht gegeben, die seit vielen Jahren geltenden Grundsätze umzukehren?
Alex, übertreibe nicht, die TF-Klebung war notwendig, um alle anderen TFs korrekt zu berechnen, nachdem sie beschlossen hatten, alle TFs von M1 aus zu berechnen.
Wenn Sie sich erinnern, konnten wir damit bis zu 21 TFs (einschließlich Nicht-Standard-TFs) berechnen.
Es wurde nicht mehr als einmal darüber berichtet. Wir werden nicht zu dem alten System zurückkehren, bei dem jede TF separat gespeichert wurde, wie Sie verstehen.
Aber die Tatsache, dass die Implementierung mehr Probleme für Programmierer mit sich bringt, ist eine Tatsache. Und die Frage ist einfach zu lösen, aber nein, wir wissen besser, was Sie brauchen :(
Das ist es, was ich mich frage.
Если вам это не удобно - ограничивайте использование этой истории вручную.
Alex übertreibt nicht, die TF-Klebung war notwendig, um alle anderen TFs korrekt zu berechnen, nachdem die Entscheidung getroffen wurde, alle TFs von M1 aus zu berechnen.
Das Problem wird dadurch gelöst, dass in der Historie ein Bezeichner gesetzt wird und beim Lesen die Daten des Taktes, wenn sie nicht zu M1 gehören, nicht in M1 ausgegeben werden, und wenn sie nicht zu M5 gehören, werden sie nicht in M5 ausgegeben. Oder ja... wir sollten das Datum, an dem die Balken der aktuellen Periode mit denen der höheren Periode zusammengeführt werden, in FirstDate schreiben, und der Benutzer wird eine echte Möglichkeit haben, zu wissen, ab welchem Datum er mit der Verarbeitung beginnen muss, damit er keine älteren Balken erwischt.
Die Situation ist in der Tat idiotisch.
Sie können weder solche Diagramme zeichnen noch solche Werte aus Funktionen zurückgeben.
Wenn Sie aus M1 bauen wollen, bauen Sie es. Nicht genug M1 - finden Sie heraus, wie Sie da rauskommen, aber nicht auf unsere Kosten.
(alle natürlich an MQ gerichtet)
- www.mql5.com
Ich stimme zu, das ist Unsinn.
Und wenn es Punkttrennzeichen gibt, ist es eine Schönheit.
Und Sie müssen es im Code verdrehen ((.
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Ich habe mich mit dem Service Desk in Verbindung gesetzt, weil ich ein Problem damit hatte, Kerzen mit höheren TFs an Charts mit niedrigeren TFs anzuhängen, wenn es keine Historie für die niedrigeren TFs gibt. Das heißt, wenn wir im M1-Chart an den Anfang der Geschichte gehen, sehen wir die Kerzen nicht ab M1, sondern ab D1 oder sogar ab W1. Aufgrund dieses Beitritts liefert die Funktion SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) nicht das Datum, an dem die M1-Historie endet, sondern das Datum des ersten Balkens außerhalb des Zeitrahmens, d. h. der angegebene Zeitrahmen hat keinen Einfluss auf das Ergebnis. Auf Nachfrage erhielt ich die Ausrede, dass dies für die Benutzer bequem sei und der Stichtag für jeden Zeitrahmen jedes Symbols manuell festgelegt werden sollte. Entschuldigung, aber sollte diese Funktion nicht von der Funktion SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) ausgeführt werden, und wie unterscheidet sichSERIES_FIRSTDATE vonSERIES_FIRSTDATEin der angegebenen TF M1, wenn das Ergebnis das gleiche ist?
Was ist das für ein Unsinn? Für wen und warum ist es praktisch? Niemand möchte W1-Kerzen auf M1-Charts sehen. Nun, außer für Masochisten ...
Ich komme zu folgendem Schluss: Entweder sind die Entwickler autistisch (sie leben in ihrer Welt, in der das oben und unten die Norm ist, oder eher nicht die Norm, aber die Arbeit ist 5 +), oder sie sind zu faul, um es zu beheben, oder das Prinzip des "Wie kommt es, dass wir nie falsch sind, wir sind alle gut". Nun, es gibt auch Varianten: Sie scherzen herum, sie wissen nicht, wie sie es reparieren sollen.
Auf den folgenden Screenshots ist die Verbindungslinie zwischen den verschiedenen TFs deutlich zu erkennen:
https://charts.mql5.com/1/26/eurusd-d1-metaquotes-software-corp-7.png
https://charts.mql5.com/1/26/eurusd-h4-metaquotes-software-corp.png
https://charts.mql5.com/1/26/eurusd-h1-metaquotes-software-corp-9.png
https://charts.mql5.com/1/26/eurusd-m30-metaquotes-software-corp-2.png
https://charts.mql5.com/1/26/eurusd-m15-metaquotes-software-corp-6.png
Abfrage 1:
Version und Bitrate des Terminals
Build 712 x86
Beschreibung des Problems.
Historische Daten kleinerer Zeiträume werden durch historische Daten größerer Zeiträume ergänzt. Das bedeutet zum Beispiel, dass die EURUSD-Historie auf M1 am 04.01.1999 endet und links davon ein D1-Chart für den Zeitraum vor dem 04.01.1999 an das M1-Chart angehängt ist.
Sie können es auf den beigefügten Bildschirmfotos sehen. Aus diesem Grund funktioniert die Funktion SeriesInfoInteger mit dem Parameter SERIES_FIRSTDATE nicht korrekt. Die Funktion liefert das erste Datum der gesamten Historie (einschließlich der Zeitrahmen D1, W1 und MN1) anstelle des ersten Datums des Symbolzeitraums.
Die Reihenfolge der Maßnahmen
Blättern in der Tabelle bis zum Beginn der Geschichte
Das erzielte Ergebnis
Fortsetzung des Charts mit historischen Daten aus größeren Zeiträumen.
Erwartetes Ergebnis
Einschränkung des Diagramms am Ende der Verlaufsdaten auf den angegebenen Zeitrahmen.
Zusätzliche Informationen
Antrag 2:
Terminalversion und Bitrate
712 x86 bauen
Beschreibung des Problems
Beschreibung in der Dokumentation:
SERIE_BALKEN_ZAHL.
Anzahl der Balken pro Symbol-Periode im Moment
lang
SERIE_ERSTDATUM
Das erste Datum des aktuellen Symbolzeitraums
datetime
Aufgrund des Beitritts der Geschichte für die untere TF, im Falle des Fehlens der Geschichte für einen bestimmten Zeitraum auf der unteren TF, und das Vorhandensein der Geschichte für den gleichen Zeitraum auf der größeren TF, das Diagramm, zum Beispiel, M1 zeigt Kerzen aus dem Chart von D1.
Ist eine Lösung für dieses Problem in Vorbereitung? Gibt es derzeit irgendwelche Lösungen für dieses Problem, außer der manuellen Einschränkung?
Abfolge der Maßnahmen
Verwendung dieser Funktionen
Das erzielte Ergebnis
SERIES_BARS_COUNT auf niedrigen Zeitrahmen (bis D1) gibt die Anzahl der Kerzen (Balken) zurück, die zum Symbol und Zeitrahmen gehören, plus die Anzahl der Kerzen des nächstgrößeren Zeitrahmens, für den historische Daten verfügbar sind
SERIES_FIRSTDATE auf niedrigen Zeitrahmen (bis D1) gibt das Eröffnungsdatum der ersten Kerze (Bar) in der Historie zurück.
Das erwartete Ergebnis
SERIES_BARS_COUNT liefert die Anzahl der Kerzen (Balken), die zu einem bestimmten Symbol und Zeitrahmen gehören
SERIES_FIRSTDATE liefert das Datum der ersten geöffneten Kerze (Bar), die zu einem bestimmten Symbol und Zeitrahmen gehört.
Mehr Infos
...
Die Funktionen arbeiten korrekt.
Was Sie sehen, ist eine Folge Ihrer vorherigen Qualitätsabfrage.
Die Geschichte ist, was sie ist. Wir haben keine tiefgründige Geschichte. Der Einfachheit halber wird der tiefere Verlauf durch tägliche Balken dargestellt.
Wenn es für Sie unpraktisch ist, schränken Sie die Verwendung dieses Verlaufs manuell ein.