Errori, bug, domande - pagina 570

[Rashid Umarov]

Vedere Proprietà del programma (#property):

tester_indicator	string	Имя пользовательского индикатора в формате "имя_индикатора.ex5". Необходимые для тестирования индикаторы определяются автоматически из вызова функций iCustom(), если соответствующий параметр задан константной строкой. Для остальных случаев (использование функции IndicatorCreate() или использование неконстантной строки в параметре, задающем имя индикатора) необходимо данное свойство
tester_file	string	Имя файла для тестера с указанием расширения, заключенное в двойные кавычки (как константная строка). Указанный файл будет передан тестеру в работу. Входные файлы для тестирования, если необходимы, должны указываться всегда
tester_library	string	Имя библиотеки с расширением, заключенное в двойные кавычки. Библиотека может быть как с расширением dll, так и с расширением ex5. Необходимые для тестирования библиотеки определяются автоматически. Однако, если какая-либо библиотека используется пользовательским индикатором, то необходимо использовать данное свойство

[Konstantin Chernov]

Rosh:

Vedere Proprietà del programma (#property):

Grazie.

[gumgum]

Sul grafico in tick (nella panoramica del mercato) sul conto demo XAUUSD c'è un reset costante.

Anche:

Aprire "dettagli" e passare il mouse sullo spazio vuoto

[Alexey Da]

gumgum:

Sul grafico in tick (nella panoramica del mercato) sul conto demo XAUUSD c'è un reset costante.

Anche:

Aprire "dettagli" e passare il mouse sullo spazio vuoto

Non sono sicuro di cosa significhi un reset permanente.

Quale sistema operativo, quale sistema operativo e capacità del terminale?

[x572intraday]

Rosh:

Imparare, perché dice nella scrittura della documentazione - Indicatori tecnici:

Significa che al primo avvio dell'indicatore (quando si passa a un nuovo timeframe per la prima volta ), i valori dell'indicatore non sono ancora stati calcolati, quindi prev_calculated=0. Quando si ritorna a questo timeframe, l'indicatore non viene creato di nuovo, poiché il suo handle è ancora vivo. Pertanto, prev_calculato!=0

Stavo per prenderti in parola, ma ho cambiato idea. I risultati che ho ottenuto all'esterno dicono quasi che non è sempre tutto così liscio, ci sono alcune eccezioni... ma non ho ancora capito se loro, queste eccezioni, sono legate alle maniglie o è qualche altro intoppo?

"Nota: se la funzione OnCalculate restituisce un valore nullo, i valori dell'indicatore non vengono mostrati nella DataWindow del terminale client. "Mi affretto ad assicurarvi: è molto peggio, se sono riuscito a mettere in relazione i risultati nella mia testa con la documentazione e a interpretare da solo l'effetto risultante. Non solo i valori dell'indicatore non vengono visualizzati - l'intero indicatore smette di funzionare, la coda dei comandi si blocca e non si può aspettare che i prossimi comandi vengano elaborati. In effetti, questo è quello che sono riuscito a intravedere in alcuni dei miei post precedenti.

Come già detto, il codice ha un sacco di Copy... ...che non coinvolge un handle, (cioè tutto tranne CopyBuffer). Se il risultato della copia <= 0, otteniamo il return(0), dopo di che"l'indicatore ha smesso di funzionare" e l'indicatore ottiene una paralisi completa.

Voglio ricordarvi che il non disegno iniziale con la paralisi che ne consegue avviene in modalità senza finestra del terminale (cioè, durante il fine settimana o off-line). Non consideratelo poco importante, perché nessuno vuole fare il debug dei propri indicatori durante il fine settimana, facendo gesti inutili, scorrendo i timeframe e iniziando artificialmente - manualmente - il primo disegno. E non si tratta solo di debugging.

Onestamente, non ho avuto abbastanza mente per collegare i link gentilmente forniti agli esempi dalla documentazione, dove si dice di aumentare il contatore di riferimento alla maniglia già esistente (così come con altre risposte date) al problema esistente. Non credo affatto che stia crescendo da lì.

Provate a riprodurre il codice allegato nelle seguenti condizioni: il timeframe preimpostato nel codice è D1, il timeframe corrente nel terminale è D1, il terminale è in modalità offline. Quando l'indicatore è collegato al grafico con il timeframe corrente specificato, i risultati della registrazione appariranno immediatamente nella scheda Experts.

Ora scaricate completamente il terminale, riavviatelo e passate a un timeframe diverso da D1 . Metti l'indicatore - non cambierà fino a quando non passerai a qualsiasi altro timeframe (non necessariamente D1).

A causa di questa spiacevole caratteristica una buona idea scompare insieme all'indicatore sottoscritto.

Gli sviluppatori, sono sicuro, possono trovare spiegazioni per questo comportamento dell'indicatore, ma non è giusto, quando i dati di TF master-defined nel suo handle sono perfettamente visualizzati, quando un utente è a quel timeframe, ma se è in un altro, deve fare movimenti inutili. Io sono per l'uguaglianza dei timeframes quando si usano maniglie di indicatori esterni, gli altri TF non sono colpevoli di nulla.

P.S.: Allora... Aspetta. Ho controllato ancora una volta - risulta che CopyHigh non influenza nemmeno questa paralisi. Ora non capisco più niente. Tutti i miei sospetti caddero improvvisamente su una maniglia di OnInit...

P.P.S.: aggiunto secondo esempio di codice - anche questo non risponde.

[x572intraday]

Il confine del problema è stato trovato.

Commentate:

   SetIndexBuffer(0,FractalUpBuffer,INDICATOR_DATA);
   PlotIndexSetInteger(0,PLOT_ARROW,217);
   PlotIndexSetInteger(0,PLOT_ARROW_SHIFT,ArrowShift);

- e il problema sparisce, ma allora è una chiara indicazione di un occasionale legame errato del buffer tramite SetIndexBuffer . E questo già indica la necessità di abbandonare l'uso diSetIndexBuffer e ricorrere alla manipolazione manuale della dimensione del buffer monitorato.

Inoltre, l'esempio allegato dimostra ovviamente l'incapacità di BarsCalculated(handle )di calcolare in tempo i valori dell'indicatore chiamato su qualsiasi TF corrente, a meno che non coincida con uno preimpostato, o l 'indisponibilità in linea di principio a calcolare qualcosa alla prima volta (molto probabilmente questa variante). In questo caso il valore sarà <=0, return(0) e stop come risultato.

[gumgum]

alexvd:

Non è del tutto chiaro cosa significhi reset permanente.

Quale OS, quale OS e bit del terminale?

W7 e MT5 64 bit.

esempio:

XAUUSD si resetta sempre all'inizio (XAGUSD è un confronto)

[Rashid Umarov]

x100intraday:

Trova il confine del problema.

Commentate:

- e il problema scomparirà, ma allora sarà una chiara indicazione di un occasionale legame errato del buffer tramite SetIndexBuffer . E questo già indica la necessità di abbandonare l'uso diSetIndexBuffer e ricorrere alla manipolazione manuale della dimensione del buffer monitorato.

Inoltre, l'esempio allegato dimostra ovviamente l'incapacità di BarsCalculated(handle) di calcolare in tempo il valore dell'indicatore chiamato su qualsiasi TF corrente, a meno che non coincida con uno preimpostato. In questo caso il valore sarà <=0, return(0) e stop come risultato.

Per il primo esempio (non ho guardato il secondo), l'indicatore paralich ha una funzione

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
bool FillArraysFromBuffers(double &up_arrows[],datetime &up_times[],int ind_handle,int amount)
  {
   if(CopyBuffer(ind_handle,0,0,amount,up_arrows)<0) return(false);
   else CopyTime(_Symbol,PERIOD_D1,0,amount,up_times);

   return(true);
  }

Quindi, immaginate che il vostro indicatore sia su D1 e provate a copiare i dati dal timeframe H1 al suo buffer dell'indicatore. Il numero di elementi non corrisponde. Penso che sia qui che si trova il vostro problema - non c'è nessun controllo prima di copiare i dati.

Esempi di indicatori che prendono dati da altri timeframes sono disponibili nell'aiuto per ogni indicatore tecnico. Per esempio https://www.mql5.com/ru/docs/indicators/iama:

//--- узнаем количество рассчитанных значений в индикаторе
   int calculated=BarsCalculated(handle);
   if(calculated<=0)
     {
      PrintFormat("BarsCalculated() вернул %d, код ошибки %d",calculated,GetLastError());
      return(0);
     }
//--- если это первый запуск вычислений нашего индикатора или изменилось количество значений в индикаторе iAMA
//--- или если необходимо рассчитать индикатор для двух или более баров (значит что-то изменилось в истории)
   if(prev_calculated==0 || calculated!=bars_calculated || rates_total>prev_calculated+1)
     {
      //--- если массив iAMABuffer больше, чем значений в индикаторе iAMA на паре symbol/period, то копируем не все 
      //--- в противном случае копировать будем меньше, чем размер индикаторных буферов
      if(calculated>rates_total) values_to_copy=rates_total;
      else                       values_to_copy=calculated;
     }
   else
     {
      //--- значит наш индикатор рассчитывается не в первый раз и с момента последнего вызова OnCalculate())
      //--- для расчета добавилось не более одного бара
      values_to_copy=(rates_total-prev_calculated)+1;
     }

[Rashid Umarov]

x100intraday:

Provate a riprodurre il codice allegato nelle seguenti condizioni: il timeframe preimpostato nel codice è D1, il timeframe corrente nel terminale è D1, il terminale è in modalità off-line. Quando un indicatore è collegato a un grafico con il timeframe corrente specificato, i risultati della registrazione appariranno immediatamente nella scheda Esperti.

E in generale, avete provato a usare il debug invece del logging, per non avere tonnellate di messaggi? Aiuto in MetaEditor → Sviluppo del programma → Debug

[x572intraday]

Rosh:

Quindi immaginate che il vostro indicatore sia su D1 e state cercando di copiare i dati dal timeframe H1 nel suo buffer dell'indicatore. Il numero di elementi non corrisponde. Penso che sia qui che si trova il vostro problema - non c'è nessun controllo prima di copiare i dati.

Prima di tutto voglio chiarire: i casi di overflow dell'array quando si copiano valori tramite le funzioni Copy...- causano un errore di overflow"Array out of range" negli esperti del terminale client? Ricordo che tali messaggi sono a volte generati dopo una compilazione riuscita, mentre l'indicatore sta lavorando, ma non so dire esattamente. Penso che non sia su Copy...-funzione, ma su un riferimento a un indice inesistente o qualcosa del genere.

In secondo luogo, mi affretto ad assicurarvi che la vostra ipotesi di assenza di controllo non è del tutto corretta. Può parlare solo del filtro if-else generato in modo errato, ma non della sua completa assenza. Ci sono inciampato più di una dozzina di volte. Recentemente ho posto qui o in "Dummies" una domanda sull'analogo di rates_total per timeframes, diverso da quello attuale, ma non ho ricevuto risposta da nessuno. La questione è che rates_total è uno dei parametri per il timeframe corrente, ed è assolutamente inutile per me, perché lavoro con un sacco di altri timeframe, e se mi capita di usare uno di quelli preimpostati, uso ancora universal calculated=BarsCalculated(handle) per i calcoli invece di rates_total. Forse sto facendo un grosso errore, ma non vedo l'utilità di rates_total per questo compito.

In terzo luogo, da molto tempo sono in grado di ottenere che, essendo in un alto TF, posso copiare e ridistribuire con successo i valori dei TF inferiori, e viceversa. Gli esempi che ho fatto qualche giorno fa sono minimi ma esaustivi, è tutto lì. La discrepanza tra le quantità di due diversi TF può essere di due tipi: carenza e eccesso di offerta. Il primo caso non è terribile, ma controllerò il secondo per l'overflow e cercherò di limitarlo, se qualcosa non va. Ma si blocca anche se le barre copiate da un altro timeframe sono più piccole del numero di barre in quello corrente.

In quarto luogo, l'indicatore è stato cotto e verificato già da circa una settimana, non ha mostrato alcun errore evidente (né alla compilazione né durante il funzionamento), ci sono solo alcuni problemi impliciti, uno dei quali è il non disegno iniziale delle barre in certi TF e il forte aumento del tempo di calcolo su M1 quando si passa di nuovo ad esso (durante la prima volta tutto viene calcolato entro 2-3 secondi). L'indicatore sembra soffocare nei calcoli (perdita di memoria a valanga?) Ho limitato il numero di elementi copiati usando CopyBuffer - a 200 invece che l'intera storia, ma non ha cambiato la situazione. Ho notato che offline su M1 e ovunque il calcolo è sempre veloce, come per la prima volta, online la situazione cambia drammaticamente (probabilmente, il problema è proprio in quel filtro, che salta qualcosa su ogni tick, anche se non dovrebbe essere, perché la frequenza di ridisegno dipende dal ridisegno di una nuova barra zero e non può essere precedente al più giovane TF preimpostato in uno degli handle). Piccoli ma spiacevoli problemi: il minimo tentativo di scorrere il grafico con la rotella del mouse smaterializza tutti i frattali e bisogna aspettare che vengano ricalcolati e disegnati (anche se non sono arrivate nuove barre, sembra non ci sia nulla da ricalcolare).