Errori, bug, domande - pagina 2179

[Artyom Trishkin]

Nikolai Semko:

No, non ha niente a che vedere con il caricamento.

Se non si prende una barra di partenza zero, ma diciamo 50 barre, allora tutto va bene. Istantaneo.

E se lo porto fino a 30 bar compresi, si blocca. Dopo di che, non lo fa.

È SICURAMENTE UN BUG!

Prova questo:

//+------------------------------------------------------------------+
//| Возвращает смещение бара по времени                              |
//| 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:

Prova questo:

Cosa c'entra iBarShift?

Si tratta di un bug nella funzione standard Bars

[Artyom Trishkin]

Nikolai Semko:

Cosa c'entra iBarShift?

Si tratta di un bug nella funzione standard Bars

Anche questa funzione usa Bars(). Avete iniziato con l'analogo di iBarShift()

[Nikolai Semko]

Artyom Trishkin:

Anche questa funzione usa Bars(). Nel vostro caso, tutto è iniziato con l'analogo di iBarShift()

Sì, certo, usando la controparte iBarShift ha rivelato questo problema.

Se usate la funzione iBarShift data da voi, non prenderete questo bug, perché solo una TF è usata lì,

E questo bug accade quando si usano TF diversi nelle funzioni CopyTime e Bars.

Ma Bars dovrebbe funzionare normalmente per qualsiasi tempo. Ma il mio esempio mostra che c'è un caso speciale, in cui iBar si blocca per decine di secondi. E non ha niente a che vedere con la storia del carico.

[Vitaly Muzichenko]

Nikolai Semko:

Sì, certo, usando la controparte iBarShift ha rivelato questo problema.

Se usate la funzione iBarShift data da voi, non prenderete questo bug, perché solo una TF è usata lì,

E questo bug accade quando si usano TF diversi nelle funzioni CopyTime e Bars.

Ma Bars dovrebbe funzionare normalmente per qualsiasi tempo. Ma il mio esempio mostra che c'è un caso speciale, in cui iBar si blocca per decine di secondi. E non ha niente a che vedere con la storia del carico.

Questo è molto probabilmente dovuto al caricamento della storia

[Kirill Belousov]

Nikolai Semko:

Sì, certo, usando la controparte iBarShift ha rivelato questo problema.

Se usate la funzione iBarShift data da voi, non prenderete questo bug, perché solo una TF è usata lì,

E questo bug accade quando si usano TF diversi nelle funzioni CopyTime e Bars.

Ma Bars dovrebbe funzionare normalmente per qualsiasi tempo. Ma il mio esempio mostra che c'è un caso speciale, in cui iBar si blocca per decine di secondi. E non ha niente a che vedere con la storia del carico.

Penso che ci sia un tentativo di sincronizzazione ciclica in una situazione in cui non ci sono barre nell'intervallo richiesto - Bars sta cercando duramente di "lavorare normalmente" e poi si arrende con un timeout o un numero di tentativi di sincronizzazione.

Dovreste controllare voi stessi i valori per evitare di chiamare Bars in un caso simile.

[Nikolai Semko]

Vitaly Muzichenko:

Questo è molto probabilmente dovuto al caricamento della storia

Non sono d'accordo. Non sarebbe stato scaricato di nuovo per 22 secondi. Inoltre, ho tutta la storia di tutti i TF caricata da un indicatore speciale.

Se fosse un caricamento, allora come si spiega che le prime 31 barre hanno bisogno di caricamento e le successive no.

[A100]

Nikolai Semko:

Se fosse un sottocarico, allora come si spiega che le prime 31 battute hanno bisogno di un sottocarico e le successive no.

Dalla documentazione: quando si richiede il numero di barre in un dato intervallo di date, vengono prese in considerazione solo le barre il cui orario di apertura cade in quell'intervallo.

Di conseguenza, il prototipo Bars() restituisce zero, che viene interpretato come nessuna storia e ::Bars() nel caso dello script, come correttamente notato in un post precedente, termina per timeout o numero di tentativi falliti.

[Nikolai Semko]

Kirill Belousov:

Penso che ci sia un tentativo di sincronizzazione ciclica quando non ci sono barre nell'intervallo richiesto - Bars sta cercando duramente di "lavorare normalmente" e poi si arrende per timeout o numero di tentativi di sincronizzazione

La ragione di questi casi è che non si dovrebbe chiamare Bars per controllare i valori da soli.

È abbastanza possibile.
Ma ci sono molte opzioni.

I bar sono una funzione molto importante, ed è difficile farne a meno. Per essere precisi, potete farne a meno, ma vi costerà una grande quantità di risorse.

Dovete assicurarvi che funzioni perfettamente.

[Nikolai Semko]

A100:

Dalla documentazione: quando si richiede il numero di bar in un dato intervallo di date, solo i bar i cui orari di apertura rientrano in questo intervallo sono presi in considerazione.

Di conseguenza, il prototipo Bars() restituisce zero, che viene interpretato come una mancanza di storia e lo script, come correttamente notato in un messaggio precedente, termina per timeout o numero di tentativi falliti.

È chiaro che è zero.

E cosa - va bene impiegare 22 secondi per decidere che zero barre in un dato intervallo di tempo?

C'è un evidente bug algoritmico nell'implementazione interna di Bars.

Dovremmo inviare una richiesta al Service Desk su questo argomento - il fine settimana è davanti e l'argomento potrebbe perdersi il lunedì.