Fehler, Irrtümer, Fragen - Seite 2179

[Artyom Trishkin]

Nikolai Semko:

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:

//+------------------------------------------------------------------+
//| Возвращает смещение бара по времени                              |
//| https://www.mql5.com/ru/code/1864                                |
//+------------------------------------------------------------------+
int iBarShift(const string symbol_name,const ENUM_TIMEFRAMES timeframe,const datetime time,bool exact=false)
  {
   datetime last_bar;
   if(!SeriesInfoInteger(symbol_name,timeframe,SERIES_LASTBAR_DATE,last_bar))
     {
      datetime array[1];
      if(CopyTime(symbol_name,timeframe,0,1,array)==1)
         last_bar=array[0];
      else
         return WRONG_VALUE;
     }
   if(time>last_bar)
      return(0);
   int shift=Bars(symbol_name,timeframe,time,last_bar);
   datetime array[1];
   if(CopyTime(symbol_name,timeframe,time,1,array)==1)
      return(array[0]==time ? shift-1 : exact && time>array[0]+PeriodSeconds(timeframe) ? WRONG_VALUE : shift);
   return WRONG_VALUE;
  }
//+------------------------------------------------------------------+

[Nikolai Semko]

Artyom Trishkin:

Versuchen Sie dies:

Was hat iBarShift mit irgendetwas zu tun?

Es handelt sich um einen Fehler in der Standardfunktion Bars

[Artyom Trishkin]

Nikolai Semko:

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()

[Nikolai Semko]

Artyom Trishkin:

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.

[Vitaly Muzichenko]

Nikolai Semko:

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

[Kirill Belousov]

Nikolai Semko:

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.

[Nikolai Semko]

Vitaly Muzichenko:

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.

[A100]

Nikolai Semko:

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.

[Nikolai Semko]

Kirill Belousov:

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.

[Nikolai Semko]

A100:

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.