Errori, bug, domande - pagina 1781

Nuovo commento
 

Prestazioni instabili

  • Percorso di localizzazione dell'indicatore: \Indicatori\Test_i.ex5
  • Percorso di destinazione dell'Expert Advisor: \Experts\Test.ex5
  • Percorso della posizione dello script: \Scripts\Test_s.ex5

Sequenza di passi: Collega lo script 'Test_s.ex5' più volte al grafico M15 (simbolo EURUSD)

Risultato:

2017.02.05 15:17:59.076 OnStart 1a volta allegato
2017.02.05 15:18:03.293 OnStart 2nd time attached
2017.02.05 15:18:07.760 OnStart 3a volta inserito
2017.02.05 15:18:07.778 OnInit
2017.02.05 15:18:07.781 OnDeinit:1
2017.02.05 15:18:16.891 OnStart 4a volta unita

I risultati delle unioni sono diversi. Non ci si aspetta che siano diversi, ma il risultato è casuale: la linea con OnInit\OnDeinit può apparire dalla 1a volta, o dalla 10a volta

//Test_i.mq5 //Индикатор
void OnInit()                    { Print( __FUNCTION__ ); }
void OnDeinit( const int reason ) { Print( __FUNCTION__, ":", reason ); }
int OnCalculate( const int, const int, const int, const double& [] ) { return 0; }
//Test_s.mq5 //Скрипт
#import "..\\Experts\\Test.ex5"
        void OnInit();
#import
void OnStart()
{
        Print( __FUNCTION__ );
        OnInit();
}

File esperto allegato (in realtà usato come libreria), codice qui https://www.mql5.com/ru/forum/1111/page1801#comment_4059227

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • www.mql5.com
Форум алго-трейдеров MQL5
File:
Test.mq5  1 kb
 

Non capisco se l'errore è mio o del terminale

Alla 5a cifra
void OnStart()
  {

double A=1.11111;
double B=1.11111;
double C=1.11111;

long CalcX=
NormalizeDouble(A,Digits)*MathPow(10,(Digits+1)*3-1)+
NormalizeDouble(B,Digits)*MathPow(10,(Digits+1)*2-1)+
NormalizeDouble(C,Digits)*MathPow(10,(Digits+1)*1-1);

Print ("CalcX=",CalcX);  
  }

Stampa CalcX=11111111111111111104 valore atteso CalcX=111111111111111111111111

 
A100:

Ordine errato delle chiamate di funzione quando si cambia il periodo del grafico

  • Percorso dell'indicatore: \Indicatori\Test_i.ex5
  • Percorso della posizione dell'esperto: {Experts\Test.ex5

Sequenza di azioni:

  1. Collega l'Expert Advisor 'Test.ex5' al grafico M5 (simbolo GBPUSD)
  2. Cambia il periodo del grafico in M15
  3. Cambia il periodo del grafico in M30
  4. Rimuovere l'Expert Advisor dal grafico

Mostra i registri. In modo che possiate vedere l'arco di tempo.

Resta da aggiungere qui che aggiungere un indicatore al grafico e rimuovere un indicatore dal grafico sono operazioni non sincrone.

Inoltre, quando il timeframe viene cambiato, l'indicatore non viene immediatamente scaricato da questo timeframe. E crea una nuova copia dell'indicatore sul nuovo timeframe. Vedo le tue stampe nel costruttore-distruttore, pensi che il distruttore sia chiamato immediatamente? No, vi sbagliate. Il distruttore viene chiamato quando l'indicatore viene scaricato e l'indicatore viene scaricato solo in pochi secondi dopo la sua cancellazione
 
Slawa:
Mostra i registri. Così potete vedere la tempistica.
Resta da aggiungere che aggiungere un indicatore a un grafico e rimuovere un indicatore da un grafico sono operazioni non sincrone.
Inoltre, quando si cambia il timeframe, l'indicatore non sarà immediatamente scaricato da questo timeframe. E crea una nuova copia dell'indicatore sul nuovo timeframe. Vedo le tue stampe nel costruttore-distruttore, pensi che il distruttore sia chiamato immediatamente? No, vi sbagliate. Il distruttore viene chiamato quando l'indicatore viene scaricato e l'indicatore viene scaricato solo pochi secondi dopo aver rimosso l'indicatore

Si presume che ci sia abbastanza tempo tra i passi (il periodo del grafico cambia)

2017.02.05 19:49:49.984 I::I->M5 #step 1: join
2017.02.05 19:49:49.984 OnInit->M5
2017.02.05 19:51:39.853 I::I->M15 #step 2: cambio periodo M5 ->M15
2017.02.05 19:51:39.853 OnInit->M15
2017.02.05 19:53:29.813 OnDeinit->M15:3 #step 3: cambio periodo M15->M30
2017.02.05 19:53:29.813 I::~I->M15
2017.02.05 19:53:29.864 I::I->M30
2017.02.05 19:53:29.864 OnInit->M30
2017.02.05 19:54:03.245 OnDeinit->M30:3 #step 4: cambio periodo M30->H1
2017.02.05 19:54:03.245 I::~I->M30
2017.02.05 19:54:03.286 I::I->H1
2017.02.05 19:54:03.286 OnInit->H1
2017.02.05 19:55:02.984 I::I->H4 #step 5: cambio periodo H1 ->H4
2017.02.02.05 19:55:02.984 OnInit->H4
2017.02.05 19:55:02.984 OnDeinit->H1:3
2017.02.05 19:55:02.984 I::~I->H1
2017.02.05 19:55:50.697 I::I->D1 #step 6: cambio periodo H4 ->D1
2017.02.05 19:55:50.697 OnInit->D1
2017.02.05 19:55:50.697 OnDeinit->H4:3
2017.02.05 19:55:50.697 I::~I->H4
2017.02.05 19:56:11.122 OnDeinit->M5:1 #step 7: delete
2017.02.05 19:56:11.122 I::~I->M5
2017.02.05 19:56:11.122 OnDeinit->D1:1
2017.02.05 19:56:11.123 I::~I->D1

La non simultaneità riguarda solo il diverso ordine delle chiamate di funzione all'interno di un passo (come visto nei passi #3 e #5)

Come potete vedere, tutti i successivi cambiamenti di periodo del grafico, eccetto il primo (passo#2:due linee di uscita), sono attesi (simile al passo#3:quattro linee di uscita). E perché il primo cambio di periodo del grafico dovrebbe essere diverso da tutti gli altri? Come è meglio/peggio? Perché le due linee di output mancanti dal passo#2 (e solo quella) si sono spostate al passo#7 (evidenziato in rosso)?

 
-Aleks-:

Non capisco se l'errore è mio o del terminale

Stampa CalcX=11111111111111111104 valore atteso CalcX=111111111111111111111111

Se il numero di decimali significativi nel doppio è > DBL_DIG=15, le regole normali non funzionano
 
A100:

Si presume che ci sia abbastanza tempo tra i passi (il periodo del grafico cambia)

2017.02.05 19:49:49.984 I::I->M5 #step1: join
2017.02.05 19:49:49.984 OnInit->M5
2017.02.05 19:51:39.853 I::I->M15 #step 2: cambio periodo M5 ->M15
2017.02.05 19:51:39.853 OnInit->M15
2017.02.05 19:53:29.813 OnDeinit->M15:3 #step 3: cambio periodo M15->M30
2017.02.05 19:53:29.813 I::~I->M15
2017.02.05 19:53:29.864 I::I->M30
2017.02.05 19:53:29.864 OnInit->M30
2017.02.05 19:54:03.245 OnDeinit->M30:3 #step 4: cambio periodo M30->H1
2017.02.05 19:54:03.245 I::~I->M30
2017.02.05 19:54:03.286 I::I->H1
2017.02.05 19:54:03.286 OnInit->H1
2017.02.05 19:55:02.984 I::I->H4 #step 5: cambio periodo H1 ->H4
2017.02.02.05 19:55:02.984 OnInit->H4
2017.02.05 19:55:02.984 OnDeinit->H1:3
2017.02.05 19:55:02.984 I::~I->H1
2017.02.05 19:55:50.697 I::I->D1 #step 6: cambio periodo H4 ->D1
2017.02.05 19:55:50.697 OnInit->D1
2017.02.05 19:55:50.697 OnDeinit->H4:3
2017.02.05 19:55:50.697 I::~I->H4
2017.02.05 19:56:11.122 OnDeinit->M5:1 #step 7: delete
2017.02.05 19:56:11.122 I::~I->M5
2017.02.05 19:56:11.122 OnDeinit->D1:1
2017.02.05 19:56:11.123 I::~I->D1

La non simultaneità riguarda solo il diverso ordine delle chiamate di funzione all'interno di un passo (come visto nei passi #3 e #5)

Come possiamo vedere, tutti i successivi cambiamenti di periodo del grafico, tranne il primo (passo #2), avvengono come previsto (simile al passo #3). Perché il primo cambio di periodo dovrebbe essere diverso da tutti gli altri? Come è meglio/peggio?

Lasciatemi provare a spiegare di nuovo

C'è una specie di indicatore sul grafico M5. Quando si cambia timeframe da M5 a M15 viene creata una seconda copia dello stesso indicatore. Un comando viene inviato a entrambi gli indicatori - il primo a M5 Deinit, il secondo a M15 Init. Allo stesso tempo, non sappiamo quale di questi comandi sarà eseguito prima dell'altro - c'è una classica corsa tra i diversi thread.

Dopo di che il primo indicatore avrà il suo contatore d'uso diminuito. In alcuni secondi dopo che il contatore di utilizzo diventa zero, l'indicatore sarà scaricato dal grafico. A quel punto i distruttori degli oggetti globali di questo indicatore saranno chiamati
 
Slawa:
Lasciatemi provare a spiegare di nuovo

C'è un certo indicatore sul grafico M5. Quando si cambia timeframe da M5 a M15 viene creata una seconda copia dello stesso indicatore. Un comando viene inviato a entrambi gli indicatori - il primo a M5 Deinit, il secondo a M15 Init. Allo stesso tempo, non sappiamo quale di questi comandi sarà eseguito prima dell'altro - c'è una classica corsa tra i diversi thread.

Dopo di che il primo indicatore avrà il suo contatore d'uso diminuito. In alcuni secondi dopo che il contatore di utilizzo diventa zero, l'indicatore sarà scaricato dal grafico. I distruttori degli oggetti globali di questo indicatore saranno chiamati

Affermo (e propongo di verificarlo) che quando il timeframe viene cambiato da M5 a M15 nessun comando M5 Deinit viene inviato al primo indicatore (e solo ad esso - in questo caso M5) e non viene scaricato dal grafico finché l'utente non rimuove l'EA

Se la struct I in 'Test_i.ex5' è esclusa (nessun effetto), l'output è semplificato:


2017.02.05 20:49:06.842 OnInit->M5
 2017.02.05 20:49:21.253 OnInit->M15(*) cambio di periodo M5 -> M15: l'indicatore M5 non è scaricato
2017.02.05 20:56:40.001 OnDeinit->M15:3 cambio di periodo M15 -> M30: l'indicatoreM15 viene scaricato immediatamente
 2017.02.05 20:56:40.132 OnInit->M30

Sono passati più di 5 minuti da (*), ma l'indicatore M5 non si è scaricato

Rimuovere l'Expert Advisor dal grafico

2017.02.05 20:57:35.176 OnDeinit->M5:1 l'indicatore M5 viene scaricato solo dopo aver rimosso l'Expert Advisor
 2017.02.05 20:57:35.177 OnDeinit->M30:1

 
Slawa:
Lasciatemi provare a spiegare di nuovo

C'è un certo indicatore sul grafico M5. Quando si cambia timeframe da M5 a M15, viene creata una seconda copia dello stesso indicatore. Un comando viene inviato a entrambi gli indicatori - il primo a M5 Deinit, il secondo a M15 Init. Allo stesso tempo, non sappiamo quale di questi comandi sarà eseguito prima dell'altro - c'è una classica corsa tra i diversi thread.

Dopo di che il primo indicatore avrà il suo contatore d'uso diminuito. In alcuni secondi dopo che il contatore di utilizzo diventa zero, l'indicatore sarà scaricato dal grafico. A questo punto i distruttori degli oggetti globali di questo indicatore saranno chiamati
Puoi spiegare di quali fili stiamo parlando? Tutti gli indicatori di un simbolo non funzionano in un unico thread?
 
Vladimir Gribachev:

Glitches durante l'installazione degli indicatori di Bill Williams

Ho messo frattali - fa

impostare AO - impostare ADX

costruire 1031

Bug vecchio di centinaia di anni con il menu che non si aggiorna quando si cambia la struttura della directory /MQx/Indicators :-) Il bug è così vecchio che è già percepito come una caratteristica, fateci l'abitudine... l'usabilità è martellata con un bullone quadrato, ma il numero pi greco conta di più :-)
 
A100:
Se il numero di cifre decimali significative nel doppio > DBL_DIG=15, allora le regole normali non funzionano

Quali funzionano?

Nel file di aiuto si dice che il valore massimo per long è9223372036854775807 - ovviamente non lo raggiungo.

1...177417751776177717781779178017811782178317841785178617871788...3184
Nuovo commento