Errori, bug, domande - pagina 3029

[mktr8591]

Igor Makanu:

questo non dovrebbe funzionare correttamente negli indicatori:

se non mi sbaglio, nell'aiuto c'è una ripartizione dello script per la paginazione dei dati per tutti i TF e ci dovrebbe essere un avviso che i dati storici non possono essere richiesti dall'indicatore in questo modo, perché l'indicatore lavora in modo asincrono

e si raccomanda di usare BarsCalculated() una volta dopo aver legato l'handle

UPD: script per la paginazione della storia e spiegazione del perché non funziona negli indicatori:https://www.mql5.com/ru/docs/series/timeseries_access

In questo articolo è scritto solo che non è desiderabile richiedere dati da serie temporali (o richiedere SeriesInfoInteger in un ciclo) in un'indicazione

"Ricordate che inviare una richiesta di aggiornamento di una serie temporale con lo stesso periodo dell'indicatore che chiama l'aggiornamento è altamente indesiderabile. L'indesiderabilità della richiesta che utilizza lo stesso symbol-period dell'indicatore è dovuta al fatto che l'aggiornamento dei dati storici viene eseguito nello stesso thread in cui lavora l'indicatore. Pertanto, c'è un'alta probabilità di un cuneo".

Se richiediamo semplicemente SeriesInfoInteger e, in caso di falso, usciamo da OnCalculate, come può avvenire il cuneo?

[mktr8591]

Domanda per tutti:

l'aiuto su https://www.mql5.com/ru/docs/series/timeseries_access dice:

"Quando si chiamano funzioni che copiano dati da serie temporali, si deve tenere presente che il parametro di inizio (numero di barra, da cui iniziare a copiare i dati di prezzo) deve sempre essere all'interno della cronologia del terminale disponibile. Se abbiamo solo 100 barre, non ha senso cercare di copiare 300 barre, partendo dalla barra con indice 500. Questa richiesta sarà considerata non valida e non sarà elaborata, cioè non sarà caricata la storia dal server commerciale.

Che CopyTime darà -1, è chiaro, ma - avvierà il processo stesso per costruire una serie temporale / paginazione dalle barre del server fino all'800esimo (500 + 300) o no?

Si prega di avvisare.

[Andrey Dik]

mktr8591:

1. Questo articolo dice solo che non è desiderabile richiedere dati da serie temporali (o richiedere SeriesInfoInteger in un ciclo) in indica

"Ricorda che inviare una richiesta di aggiornamento di una serie temporale con lo stesso periodo dell'indicatore che causa l'aggiornamento è altamente indesiderabile. L'indesiderabilità della richiesta che utilizza lo stesso symbol-period dell'indicatore è dovuta al fatto che l'aggiornamento dei dati storici viene eseguito nello stesso thread in cui lavora l'indicatore. Pertanto, c'è un'alta probabilità di un cuneo".

2. Se richiedete semplicemente il SeriesInfoInteger e lasciate l'OnCalculate in caso di false, come avverrà il cuneo?

1. Sì, perché non si può rallentare il thread dell'indicatore, perché richiedere lo stato di sincronizzazione causerà lo scambio della storia, e non si può aspettare.

2. Giusto. Se i dati non sono pronti, uscirà semplicemente dall'oncalc e partirà il terminale di sincronizzazione, ma il flusso dell'indicatore non sarà inibito. Il prossimo oncalc sarà eseguito completamente e senza freni solo quando i dati sono pronti e l'indicatore richiesto è completamente contato. La stampa aggiunta sopra mostra che l'indicatore richiesto non è sempre pronto, ma possiamo permettere di fare una nuova barra solo una volta, non su ogni tick per il calcolo più veloce di tutti gli indicatori.

[mktr8591]

Andrey Dik:

Grazie.

Inoltre, vedi la mia domanda:https://www.mql5.com/ru/forum/1111/page3028#comment_22557528

[Alexey Viktorov]

Andrey Dik:

vedere il codice sopra,

correggere il codice, aggiungere una stampa

  if(SeriesInfoInteger(Symbol(), OldTF, SERIES_SYNCHRONIZED))
   {
    if(iBars(Symbol(), OldTF) != BarsCalculated(Handle))
     {
      Print("Баров ", iBars(Symbol(), OldTF));
      Print("посчитано", BarsCalculated(Handle));
      return 0;
     }
   }
  else
   {
    Print("Период ", OldTF, " не синхронизирован.");
    return 0;
   }

e quando vedi i tuoi scarafaggi, arrotola il tuo monitor in un tubo e ficcalo... sai dove.

[Andrey Dik]

mktr8591:

Grazie.

Inoltre, vedi la mia domanda:https://www.mql5.com/ru/forum/1111/page3028#comment_22557528

Non sono sicuro al 100% di questo (devo controllare), una volta che ti assicuri che la data richiesta sia più fresca della prima nella storia sul server, puoi richiedere i dati, la storia sarà scambiata.

[mktr8591]

Andrey Dik:

Non sono sicuro al 100% di questo (devo controllare), assicurandomi che la data richiesta sia più fresca della prima nella storia sul server, i dati possono essere richiesti, la storia sarà scambiata.

Grazie,

Stavo chiedendo del mio altro post, link di nuovo : https://www.mql5.com/ru/forum/1111/page3028#comment_22557528

[Andrey Dik]

Alexey Viktorov:

Correggere il codice, aggiungere una stampa

e quando vedi i tuoi scarafaggi, arrotola il tuo monitor e ficcalo... sai dove.

Stai dimostrando il mio punto di vista, compagno.

[Andrey Dik]

mktr8591:

Grazie,

Stavo chiedendo del mio altro post, link di nuovo : https://www.mql5.com/ru/forum/1111/page3028#comment_22557528

Non capisco bene il tuo codice. Cosa dovrebbe succedere dopo "return 0;" nella prossima chiamata a OnCalculate?

Restituiamo 0, dichiarando così che non abbiamo ancora calcolato nulla e che il kalk prev non sarà incrementato di 1 sulla prossima barra.

cioè saremo sulla barra in cui abbiamo iniziato a richiedere i dati dal vecchiof fino a quando non restituiamo(rates_total)

[[Eliminato]]

Andrey Dik:

Stai dimostrando il mio punto di vista, compagno.

1. Grazie a tutti - sono diventato un po' più esperto di indicatori ))))

2) Andrew, se qualcuno non capisce le tue idee (me compreso), significa solo una cosa: non disegni correttamente il quadro! Più precisamente - lo disegni in un modo tale che molte persone non lo capiscono...