Sequenza di esecuzione di Init() e DeInit() - pagina 5
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Lo capisco. Stavo chiedendo la logica della sequenza delle operazioni. Ed ecco che ci manca. A volte OnDeinit viene eseguito per primo (come dovrebbe essere secondo la logica di un profano) e a volte OnInit viene eseguito per primo.
Capisco che la risposta è nella linea"Per un certo tempo (un tempo molto breve) entrambe le copie dell'indicatore esistono in parallelo". Ma questo non rende la questione più chiara.
La funzione OnInit deve essere eseguita per prima nel programma.
Puoi fare un esempio quando la sequenza OnInit -> OnDeinit non viene sempre eseguita?
La funzione OnInit dovrebbe essere eseguita per prima nel programma.
Puoi fare un esempio in cui OnInit -> OnDeinit non viene sempre eseguito?
Puoi usare un esempio dell'autore del temaERROR.mq5, che dà all'inizio. Cambia il TF e vedi cosa succede nella scheda Esperti.
Puoi usare l'esempioERROR.mq5 che dà all'inizio
Lo proverò nel corso della giornata. L'hai già usato personalmente?
Certo, l'ho usato 9 mesi fa. Puoi leggere il mio commento al numero 8 di questo thread.
No, non è così semplice. Gli indicatori si trovano all'interno di un'altra entità, il grafico, e sono subordinati ad esso (sono consapevole della loro complessa relazione uno-a-molti, ma non cambia il punto). Un grafico ha il suo ciclo di vita, che include una sorta di eventi interni di init e deinit, che sono i confini del ciclo di vita degli indicatori. In altre parole, un indicatore non può sopravvivere al suo grafico. Il deinit del grafico deve aspettare il deinit o il timeout del deinit di tutti gli indicatori. Solo allora l'init del grafico per il nuovo timeframe può essere avviato, e da esso possono essere chiamati gli init degli indicatori collegati.
I grafici sono la stessa cosa degli indicatori. Gli indicatori possono "sopravvivere" ai loro grafici.
Prima di OnInit di un indicatore/consigliere vengono eseguiti i costruttori degli oggetti globali. Dopo OnDeinit - i distruttori. Pertanto, è possibile rimuovere OnInit e OnDeinit da qualsiasi indicatore.
L'unico problema è la mancata corrispondenza delle vostre idee sugli indicatori con la realtà. Forse, questo comportamento è critico per alcuni freelance che non possono scrivere la soluzione.
Gradirei un passo avanti su questo argomento da parte degli sviluppatori. Ma ci sono due punti di vista completamente comprensibili che si scontrano qui con la loro logica, come dovrebbe essere. Nessuno dei due è più difettoso dell'altro. È solo che alcuni pensano che sia giusto così e altri pensano che sia giusto così.
Immaginate quanto sarebbero lenti i grafici se prima di cambiare il TF il terminale aspettasse lo scarico di tutti gli indicatori dal vecchio TF e solo allora costruisse e inizializzasse quello nuovo.
In quali situazioni, oltre al semplice lavoro con oggetti grafici (senza il nome di TF nel nome) è importante la sequenza DeInit - Init?
Immaginate quanto sarebbero lenti i grafici se prima di cambiare il TF il terminale aspettasse lo scarico di tutti gli indicatori dal vecchio TF e solo allora costruisse e inizializzasse quello nuovo.
In quali situazioni, oltre al semplice lavoro con oggetti grafici (senza il nome di TF nel nome) è importante la sequenza DeInit - Init?
+
Ancora una volta. Quando si cambia timeframe o simbolo nel grafico, viene creata una nuova copia dell'indicatore. Una nuova.
Per la stessa ragione per cui le parti calcolate degli indicatori vivono nelle cache della storia. Per ogni timeframe ha la sua cache di barre. Quando si cambia timeframe, diciamo EURUSD,M1 su EURUSD,H1, all'indicatore nella cache M1 viene inviato l'evento Deinit con causa 3 (cambio grafico) e dopo un po' questo indicatore verrà scaricato. Se improvvisamente questo indicatore non ha avuto il tempo di gestire il Deinit con la ragione 3, sarà deinizializzato con la ragione 1 (chiusura del grafico). Se la cache H1 non esisteva in quel momento, allora sarà creata. Dopo di che, la copia dell'indicatore NEW viene caricata nella cache H1, alla quale viene inviato l'evento Init. La nuova copia dell'indicatore non sa nulla della copia precedente, che sta per morire. Tutte le variabili della nuova copia dell'indicatore sono pulite, sono appena nate.
Se c'è un cambiamento di tempo all'interno di un singolo simbolo, l'ordine di inizializzazione/deinizializzazione è in linea di principio prevedibile. Scarica l'ultima build 1580 - abbiamo corretto alcune cose lì, ora la cancellazione degli indicatori viene eseguita nell'ultimo turno, quindi non ci dovrebbe essere una deiniterazione prematura. Ma se si cambia un simbolo, si ottiene la corsa inter-thread in forma pura, e non si può prevedere la sequenza di inizializzazione-deinizializzazione senza ambiguità. Poiché i diversi caratteri sono processati in diversi thread
Quindi un consiglio per il topic-starter. Fatevi guidare dalla causa della deinizializzazione. Se è 3, allora non c'è bisogno di restituire lo schema dei colori al grafico
Immaginate quanto sarebbero lenti i grafici se prima di cambiare il TF il terminale aspettasse lo scarico di tutti gli indicatori dal vecchio TF e solo allora costruisse e inizializzasse quello nuovo.
In quali situazioni, a parte il semplice lavoro con oggetti grafici (senza il nome di TF nel nome) è importante la sequenza DeInit - Init?
Perché dovrebbero essere lenti? A meno che l'indicatore non sia scritto male. Per un indicatore ben scritto, DeInit impiega un tempo abbastanza breve. Inoltre, la commutazione TF non è un'operazione così frequente. In alcuni casi particolarmente gravi (per indicatori "sbagliati") si può aspettare un secondo o due quando si cambiano i TF.
Pertanto, l'argomento della frenata durante la commutazione TF è più che dubbio. Inoltre, quando passiamo alla TF che non è stata ancora costruita, incontriamo anche un ritardo abbastanza apprezzabile. E nessuno piange per i freni del terminale.