Fehler, Irrtümer, Fragen - Seite 2179
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
Nein, das hat nichts mit dem Laden zu tun.
Wenn Sie nicht mit einem Null-Startbalken beginnen, sondern mit 50 Balken, dann ist alles in Ordnung. Unmittelbar.
Und wenn ich den Druck auf 30 bar erhöhe, friert er ein. Danach ist das nicht mehr der Fall.
ES IST DEFINITIV EIN FEHLER!
Versuchen Sie dies:
Versuchen Sie dies:
Was hat iBarShift mit irgendetwas zu tun?
Es handelt sich um einen Fehler in der Standardfunktion Bars
Was hat iBarShift mit irgendetwas zu tun?
Es handelt sich um einen Fehler in der Standardfunktion Bars
Diese Funktion verwendet auch Bars(). Sie begannen mit dem Analogon von iBarShift()
Diese Funktion verwendet auch Bars(). In Ihrem Fall begann alles mit dem Analogon von iBarShift()
Ja, natürlich, die Verwendung des iBarShift-Gegenstücks hat dieses Problem offenbart.
Wenn Sie die von Ihnen angegebene Funktion iBarShift verwenden, werden Sie diesen Fehler nicht bemerken, da dort nur eine TF verwendet wird,
Und dieser Fehler tritt auf, wenn Sie unterschiedliche TF in den Funktionen CopyTime und Bars verwenden.
Aber Bars sollten normalerweise für jede Zeit funktionieren. Aber mein Beispiel zeigt, dass es einen Sonderfall gibt, in dem iBar für einige Sekunden hängen bleibt. Und das hat nichts mit der Ladegeschichte zu tun.
Ja, natürlich, die Verwendung des iBarShift-Gegenstücks hat dieses Problem offenbart.
Wenn Sie die von Ihnen angegebene Funktion iBarShift verwenden, werden Sie diesen Fehler nicht bemerken, da dort nur eine TF verwendet wird,
Und dieser Fehler tritt auf, wenn Sie unterschiedliche TF in den Funktionen CopyTime und Bars verwenden.
Aber Bars sollten normalerweise für jede Zeit funktionieren. Aber mein Beispiel zeigt, dass es einen Sonderfall gibt, in dem iBar für einige Sekunden hängen bleibt. Und das hat nichts mit der Ladegeschichte zu tun.
Dies ist höchstwahrscheinlich auf die historische Belastung zurückzuführen
Ja, natürlich, die Verwendung des iBarShift-Gegenstücks hat dieses Problem offenbart.
Wenn Sie die von Ihnen angegebene Funktion iBarShift verwenden, werden Sie diesen Fehler nicht bemerken, da dort nur eine TF verwendet wird,
Und dieser Fehler tritt auf, wenn Sie unterschiedliche TF in den Funktionen CopyTime und Bars verwenden.
Aber Bars sollten normalerweise für jede Zeit funktionieren. Aber mein Beispiel zeigt, dass es einen Sonderfall gibt, in dem iBar für einige Sekunden hängen bleibt. Und das hat nichts mit der Ladegeschichte zu tun.
Ich denke, es gibt einen Versuch der zyklischen Synchronisierung in einer Situation, in der es keine Balken im angeforderten Bereich gibt - Bars versucht, "normal zu arbeiten" und gibt dann durch eine Zeitüberschreitung oder eine Anzahl von Synchronisierungsversuchen auf.
Sie sollten die Werte selbst überprüfen, um zu vermeiden, dass Bars in einem solchen Fall aufgerufen wird.
Dies ist höchstwahrscheinlich auf das Hochladen der Historie zurückzuführen
Da bin ich anderer Meinung. Es wäre erst nach 22 Sekunden wieder heruntergeladen worden. Außerdem habe ich die gesamte Historie für alle TFs durch einen speziellen Indikator geladen.
Wenn es sich um einen Ladevorgang handelte, wie lässt sich dann erklären, dass die ersten 31 Takte geladen werden müssen und die nächsten nicht.
Wenn es sich um eine Unterladung handelt, wie erklären Sie dann, dass die ersten 31 Takte eine Unterladung benötigen und die folgenden nicht.
Aus der Dokumentation: Bei der Abfrage der Anzahl der Balken in einem bestimmten Datumsbereich werden nur die Balken berücksichtigt, deren Öffnungszeit in diesen Bereich fällt.
Dementsprechend gibt der Prototyp Bars() den Wert Null zurück, was als kein Verlauf interpretiert wird, und ::Bars() wird im Fall des Skripts, wie in einem früheren Beitrag richtig bemerkt, durch Timeout oder die Anzahl der Fehlversuche beendet.
Ich denke, es gibt einen Versuch der zyklischen Synchronisation, wenn es keine Balken im angeforderten Bereich gibt - Bars versucht, "normal" zu arbeiten und gibt dann durch Timeout oder Anzahl der Synchronisationsversuche auf
Der Grund für solche Fälle ist, dass Sie Bars nicht aufrufen sollten, um die Werte selbst zu überprüfen.
Das ist durchaus möglich.
Aber es gibt viele Möglichkeiten.
Bars sind eine sehr wichtige Funktion, auf die man nur schwer verzichten kann. Um genau zu sein, können Sie darauf verzichten, aber es wird Sie eine Menge Ressourcen kosten.
Sie müssen dafür sorgen, dass es perfekt funktioniert.
Aus der Dokumentation: Bei der Abfrage der Anzahl der Bars in einem bestimmten Datumsbereich werden nur die Bars berücksichtigt, deren Öffnungszeiten in diesen Bereich fallen.
Dementsprechend gibt der Prototyp Bars() den Wert Null zurück, was als fehlende Historie interpretiert wird, und das Skript wird, wie in einer früheren Meldung richtig bemerkt, durch Timeout oder Anzahl der Fehlversuche beendet.
Es ist klar, dass sie gleich Null ist.
Und was - ist es in Ordnung, 22 Sekunden zu brauchen, um zu entscheiden, dass es in einem bestimmten Zeitbereich keine Balken gibt?
Es gibt einen offensichtlichen algorithmischen Fehler in der internen Implementierung von Bars.
Wir sollten eine Anfrage zu diesem Thema an den Servicedesk schicken - das Wochenende steht vor der Tür und das Thema könnte am Montag verloren gehen.