Sequenza di esecuzione di Init() e DeInit() - pagina 4
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
In Deinit, scrivete tutti i dati nei globali. Imposta uno dei globali come semaforo tramiteGlobalVariableSetOnCondition.
Init scrivere che se il semaforo è in stato "data dumped" leggeremo e lavoreremo impostando il semaforo in stato "read all".
Se il semaforo è "incomprensibile", allora ci limitiamo ad aspettare il semaforo (attraverso uno Sleep in loop o OnTimer).
Se non c'è nessun semaforo significa che si avvia per la prima volta e si conta tutto e allo stesso tempo si crea un semaforo per il cambiamento non futuro della TF.
Cosa c'è di così complicato in una tale implementazione? Da prescrivere una volta con una biblioteca e basta.
Se Sleep lavorasse in indicatori, sarebbe più facile. Il sonno non funziona negli indicatori.
Se si moltiplica il numero di piccole persone che - ognuna da sola, più e più volte - risolveranno un problema comune, allora le ore uomo sprecate molte volte (al limite, un numero infinito di volte ;-)) superano il tempo necessario per qualsiasi variante di editing nel terminale stesso. Anche la presenza di un'ipotetica biblioteca non garantisce che tutti siano a conoscenza della sua esistenza e abbiano bisogno di usarla. In generale, non è chiaro perché fare e lasciare tale "rastrello"?
Quindi non è un rastrellamento, è un comportamento logico quando la nuova copia dell'indicatore non conosce quella vecchia. Questo è logico!
Ma MIGLIAIA di persone vogliono una funzionalità aggiuntiva in modo che la copia lo sappia! Allora cosa impedisce a queste unità di scrivere una soluzione una volta sola e di usarla?
Perché fingere di preoccuparsi degli altri? Chi ne ha davvero bisogno, cercherà prima una soluzione. E se non lo fanno - cercheranno di scriverne uno. Un codebase centralizzato serve proprio a questo scopo.
Se Sleep lavorasse in indicatori, sarebbe più facile. Il sonno non funziona negli indicatori.
Quindi non è un rastrellamento, è un comportamento logico quando la nuova copia dell'indicatore non conosce quella vecchia. Questo è logico!
Ma MIGLIAIA di persone vogliono una funzionalità aggiuntiva in modo che la copia lo sappia! Allora cosa impedisce a queste unità di scrivere una soluzione una volta sola e di usarla?
Perché fingere di preoccuparsi degli altri? Chi ne ha davvero bisogno, cercherà prima una soluzione. E se non lo fanno - cercheranno di scriverne uno. Un kodobase centralizzato serve proprio a questo scopo.
No, non è così semplice. Gli indicatori sono all'interno di un'altra entità - un grafico, e sono subordinati ad esso (sono consapevole della loro complessa relazione uno-a-molti, ma non cambia l'essenza). 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.
Un rastrello è, per definizione, qualcosa che può essere calpestato. Già calpestato. Un buon software non permette il rake in linea di principio.
Quindi non è un rastrellamento, è un comportamento logico quando la nuova copia dell'indicatore non conosce quella vecchia. Questo è logico!
Ma MIGLIAIA di persone vogliono una funzionalità aggiuntiva in modo che la copia lo sappia! Allora cosa impedisce a queste unità di scrivere una soluzione una volta sola e di usarla?
Perché fingere di preoccuparsi degli altri? Chi ne ha veramente bisogno, cercherà prima una soluzione. E se non lo fanno - cercheranno di scriverne uno. Un kodobase centralizzato serve esattamente allo stesso scopo.
Com'è possibile che non si sappia quando si cambia timeframes e si inseriscono di nuovo i parametri di input?
E poi Deinit finirà il suo lavoro e rovinerà tutto. Non ha senso fare Init e Deinit regolari se si fanno i propri Init e Deinit personalizzati.
Anche io ho incontrato questo problema. (
Vi ho già detto tutto, ma aggiungerò altro di mio.
La peculiarità di tutti i programmi per la MT è che funzionano sulla base di eventi. OnInit e OnDeinit funzionano in modo abbastanza logico e appropriato secondo il modello degli eventi.
Ma c'è una strana sfumatura nel comportamento delle variabili d'ingresso: tutti gli indicatori di base, compresi quelli interni ai terminali e quelli che sono inclusi nella consegna standard - ogni volta vengono avviati con gli stessi parametri d'ingresso che sono stati chiamati dall'avvio precedente. È molto conveniente. Ma non c'è una cosa del genere per gli indicatori personalizzati e tutti gli Expert Advisor e gli script inclusi quelli standard, questo è un po' un inconveniente(augurio a MQ: aggiungere lo stesso comportamento per le variabili di input come per gli indicatori standard).
E ciò che riguarda il lavoro con Init e Deinit, così, personalmente, non mi sono mai adagiato su motivi di deinizializzazione dei programmi quando si lavora con variabili globali del programma, costruisco sempre la logica sotto l'idea specifica del programma. Per esempio, molto spesso è necessario salvare le variabili globali di un programma dopo la deinizializzazione di un EA (i motivi possono essere diversi, per esempio la stessa disconnessione causa OnDeinit e il successivo OnInit), quindi perché dovrei ricalcolare tutto e creare nuovi handle di indicatori, ecc?
Ecco perché, come ho scritto prima e fxsaber, se hai bisogno di salvare le variabili globali di un programma in alcuni casi - puoi farlo nelle variabili globali del terminale usando i flag appropriati.
In MQL non tutto è liscio, purtroppo, ma il lavoro di OnInit e Ondeinit è logico e comprensibile, quindi è una perdita di tempo).
Cosa vuol dire che non lo sai, quando si cambia timeframes si reinseriscono i parametri di input?
Ma il funzionamento di OnInit e Ondeinit è logico e comprensibile, quindi non c'è bisogno di farne un dramma).
Si prega di spiegare la logica della sequenza di OnInit e OnDeinit nell'indicatore quando si cambia il timeframe. Te ne sarei molto grato. E credo di non essere l'unico.
Si prega di spiegare la logica della sequenza di operazioni OnInit e OnDeinit nell'indicatore quando si cambia il timeframe. Vi sarei molto grato. E credo di non essere l'unico.
Il signor Slava l'ha detto chiaramente.
Una copia dell'indicatore viene creata e quella vecchia viene scaricata dopo un po' di tempo.
Se vogliamo salvare le variabili globali del programma, dovremmo occuparcene già prima al momento di chiamare OnInit (le variabili globali del terminale client sono buone per questo scopo).
E i buffer degli indicatori saranno ricalcolati comunque, perché le barre (candele) sono cambiate, apparentemente, ecco perché succede così (la copia sarà avviata e l'istanza dell'indicatore precedente sarà finita dal terminale).
Se lo sviluppatore dell'indicatore vede il problema nel lavorare con gli oggetti grafici, allora all'inizio dell'indicatore è necessario legare i nomi degli oggetti grafici al nome di TF, quindi la nuova copia dell'indicatore creerà nuovi oggetti, e la copia precedente dell'indicatore pulirà quelli vecchi.
Nessun problema.
Forum sul trading, sistemi di trading automatico e test di strategie di trading
Sequenza di esecuzione di Init() e DeInit()
Slawa, 2017.04.07 15:31
Che tipo di logica incasina?
Quando si cambia timeframe, viene creata una nuova copia dell'indicatore, che non sa nulla della copia precedente. Per un po' (un tempo molto breve) entrambe le copie dell'indicatore esistono in parallelo. Poi la copia precedente viene scaricata.
Leggi la documentazione https://www.mql5.com/ru/docs/runtime/running
Il signor Slava l'ha detto chiaramente.
Una copia dell'indicatore viene creata e quella vecchia viene scaricata dopo un po' di tempo.
Se vogliamo salvare le variabili globali del programma, dovremmo occuparcene già prima al momento di chiamare OnInit (le variabili globali del terminale client sono buone per questo scopo).
E i buffer degli indicatori saranno ricalcolati comunque, perché le barre (candele) sono cambiate, apparentemente, ecco perché succede così (la copia sarà avviata e l'istanza dell'indicatore precedente sarà finita dal terminale).
Se lo sviluppatore dell'indicatore vede il problema nel lavorare con gli oggetti grafici, allora quando si avvia l'indicatore, si dovrebbero legare i nomi degli oggetti grafici al nome di TF, quindi la nuova copia dell'indicatore creerà nuovi oggetti, e la copia precedente dell'indicatore pulirà quelli vecchi.
Non c'è nessun problema.
Sì, è comprensibile. Stavo chiedendo la logica della sequenza di esecuzione. Il fatto è che non c'è questa logica. A volte OnDeinit viene eseguito per primo (come dovrebbe essere secondo la logica dell'uomo comune), e a volte OnInit viene eseguito per primo.
Capisco che la risposta sta nell'osservazione"Per un certo periodo di tempo (un tempo molto breve) entrambe le copie dell'indicatore esistono in parallelo". Ma questo non rende la questione più chiara.