Sequenza di esecuzione di Init() e DeInit() - pagina 7

 
Slawa:

Se c'è un cambiamento di tempo all'interno di un simbolo, allora l'ordine di inizializzazione e deinizializzazione è in linea di principio prevedibile. Scarica l'ultima build 1580 - abbiamo corretto alcune cose lì, ora gli indicatori vengono rimossi per ultimi, quindi non dovrebbe esserci una deiniterazione prematura.

Non capisco. Si prega di chiarire. Deinit sarà garantito dopo init?
 
Andrey Khatimlianskii:

Gli indicatori sono di tutte le forme e dimensioni. Anche quelli frenati. E non tutti sono propri e in codice sorgente.

Un paio di secondi sono divertenti. L'interfaccia si sente decine di millisecondi, il disagio appare immediatamente.


Non fraintendete. Non si tratta dell'interfaccia, ma dei transitori - TF switching. Su un grafico vuoto, la commutazione TF richiede una quantità infinitesimale di tempo? No. Allora gli indicatori non c'entrano niente.



E soprattutto, non c'è una risposta alla mia domanda:
In quali situazioni, a parte il lavoro diretto con oggetti grafici (senza un nome TF nel nome), la sequenza DeInit - Init è importante?


In quasi tutte le situazioni. A meno che, naturalmente, non abbiamo a che fare con giocattoli di tipo MAshek e primitivi simili:

  1. Scrivere su file. Quando si disconnette l'indicatore è necessario salvare le informazioni accumulate in un file. Perché è impossibile tenere il file aperto tutto il tempo. C'è un rischio di crash e di perdita di tutte le informazioni registrate nel file.
  2. Quando si lavora con oggetti grafici. È una vera bellezza: un indicatore esiste ancora e non si è pulito, mentre il secondo sta disegnando sopra questi oggetti. È così che spiegheremo all'utente: "Quando si commuta il TF si osservano disturbi a breve termine". )))
  3. Lavorare con DLL. Quando Deinit DLL deve interrompere tutti i thread, che sono stati creati da essa. La copia dell'indicatore successivo li ricrea per se stessa. Ora otteniamo che la nuova copia dell'indicatore cercherà di creare tutti questi thread e sarà respinta, perché sono ancora in esecuzione. Il nuovo indicatore genererà un messaggio di errore e non funzionerà. Solo a causa del cambio di TF. Sì, il problema è risolvibile.

D'accordo. I problemi diversi dal secondo sono risolvibili se li conosci. Cioè, ora dobbiamo spingere tutta la logica in OnCalculate, mentre Init e DeInit non dovrebbero essere usati. Ma a cosa ci servono allora?

Comunque, non stiamo parlando di multipiattaforma ora. Si scopre che MT4 e MT5 hanno approcci diversi a Init e DeInit.

 
nmaratr:


Se non si trattasse di finanze, forse non ci sarebbe questa discussione.

E poiché un consulente di trading dipende da un indicatore o dall'altro, semplicemente smetterà di funzionare correttamente a causa di un semplice cambio di TF. È la cosa più stressante.

Quindi come ci si può fidare delle finanze?

Potremmo essere in disaccordo con gli sviluppatori di MT su questo argomento.

Ci sono molte opzioni per risolvere questo problema. E quasi tutti sono stati espressi in questo thread.

1. Se l'indicatore è scritto usando l'Expert Advisor, l'Expert Advisor dovrebbe essere scritto in modo tale da non essere influenzato dai cambiamenti di periodo del grafico. Quindi, l'indicatore non sarà reinizializzato.

2. Se devi cancellare oggetti grafici o cambiare il disegno del grafico in deinit, allora controlla il motivo della deinizializzazione.

3. Se l'indicatore ha bisogno di salvare alcuni parametri, allora, come è stato detto qui, non salvate questi dati all'uscita, ma quando questi dati vengono preparati o modificati.

4) Tra due mucchi di merda, scegli sempre quello che puzza meno. Di conseguenza, quando si sceglie tra la velocità da cui dipendono TUTTI gli indicatori e la complessità di salvare alcuni dati in SETTE indicatori, scelgo la velocità.

 
Stanislav Korotky:
Non capisco. Si prega di chiarire. Il deinit sarà garantito dopo l'init?

Se lo switch del timeframe scende, allora prima OnInit sul timeframe inferiore (nuovo), e poi OnDeinit sul timeframe superiore (vecchio).

Se l'interruttore va verso l'alto, allora è viceversa. Prima OnDeinit sul timeframe inferiore (vecchio) e poi OnInit sul timeframe superiore (nuovo).

Qui dobbiamo tenere a mente che le cache sono processate dal più basso al più alto lasso di tempo

 
Slawa:

Scarica l'ultima build 1580 - abbiamo sistemato alcune cose lì, ora gli indicatori vengono rimossi per ultimi, quindi non dovrebbe esserci nessuna deiniterazione prematura.


:(( Oh amico, mi hai reso felice. Ora potrei dover riscrivere il codice in alcuni programmi, perché è stato progettato per "il contrario" - prima Deunit, poi Unit.
Ad essere onesti, è una strana logica. Significa che la vecchia e la nuova copia dell'indicatore vivranno insieme senza ambiguità per un po' di tempo, fino a quando l'unità viene eseguita nella nuova copia dell'indicatore prima e la Deunit in quella vecchia dopo. In quel momento non c'è la possibilità di informare la nuova copia di alcune informazioni attraverso Deunit. Questo è ovviamente un casino. Per le unità sono di solito molto più ingombranti delle unità. Perché una sequenza di esecuzione così strana! Allora questo argomento sarà rilanciato ancora e ancora. Ma se il programmatore dell'indicatore potesse creare delle variabili che non vengono reinizializzate quando si cambia il TF, allora occupiamoci di questa sequenza di OnInit e OnDeinit. Ne ho già scritto un paio di volte(1 e 2). Sono d'accordo con la logica degli sviluppatori, che per ragioni di sicurezza i puntatori e i riferimenti non sono un lusso per i programmatori, ma se si crea un meccanismo di un tipo speciale di variabili condivise per tutte le copie dell'indicatore, dovremo creare lo stesso meccanismo per tutte le copie dell'indicatore. L'indicatore è lo stesso, le proprietà dell'indicatore sono memorizzate "da qualche parte".
 
Slawa:

Se l'interruttore del timeframe scende, prima OnInit sul timeframe più basso (nuovo) e poi OnDeinit sul timeframe più alto (vecchio).

Se l'interruttore va verso l'alto, allora è viceversa. Prima OnDeinit sul timeframe inferiore (vecchio) e poi OnInit sul timeframe superiore (nuovo).

Qui dobbiamo tenere a mente che le cache sono processate dal basso verso l'alto

Questo è ancora più confuso.

Dopotutto, se l'indicatore non è usato dall'autore stesso, allora può cambiare a suo piacimento senza aspettare l'init e il deinit? E cosa succederà? E se per una variante di interruttore in deinit è necessario fare alcune azioni, allora non fa alcuna differenza se è scritto per una direzione di interruttore o per entrambe le direzioni. Ma hanno aggiunto dei freni per gli indicatori "pesanti".

 
Alexey Viktorov:

Questo è ancora più confuso.

Dopotutto, se l'indicatore non è usato dall'autore stesso, allora può cambiare a suo piacimento e senza aspettare l'init e il deinit? E cosa succederà? E se per una variante di interruttore in deinit è necessario fare alcune azioni, allora non fa alcuna differenza, se è scritto per una direzione di interruttore o per entrambe le direzioni. Ma hanno aggiunto dei freni per gli indicatori "pesanti".

Dove sono stati aggiunti i freni? Rispetto a cosa hanno aggiunto?

Per favore supportate le vostre affermazioni con del codice, in modo che tutti possano riprodurlo.

Ancora una volta. Poiché un'altra copia dell'indicatore viene creata al cambiamentodel periodo-simbolo, l'ordine di OnInit al nuovo periodo-simbolo e OnDeinit al vecchio periodo-simbolo è indefinito

 
Slawa:

Dove sono stati aggiunti i freni? Rispetto a cosa avete aggiunto?

Siate abbastanza gentili da sostenere le vostre affermazioni con del codice in modo che tutti possano riprodurre

Ancora una volta. Poiché un'altra copiadell' indicatore viene creata quando si cambia un periodo-simbolo, l'ordine di esecuzione di OnInit sul nuovo periodo-simbolo e OnDeinit sul vecchio periodo-simbolo è indefinito

In questo messaggio

Slawa:

Se il cambio di timeframe va in crisi, allora prima OnInit sul timeframe più giovane (nuovo), e poi OnDeinit sul timeframe più vecchio (più vecchio).

Se l'interruttore va verso l'alto, allora è viceversa. Prima OnDeinit sul timeframe inferiore (vecchio), e poi OnInit sul timeframe superiore (nuovo).

Dovete tenere a mente che le cache sono elaborate da un lasso di tempo di basso ordine a uno di alto ordine.

Hai detto le cose come stanno o come hai fatto quando hai preparato la nuova costruzione?

Se è così, allora ho sbagliato e mi rimangio tutto.

 
Alexey Viktorov:

In questo messaggio.

Hai detto così com'è o come fatto preparando una nuova costruzione?

Se è così, ho capito male e me lo riprendo.

Questo viene fatto nella build 1580.

Prima di allora, la deinizializzazione al cambio di timeframe era quasi sempre precedente. Ma solo se l'interruttore del timeframe va giù, la deinizializzazione è stata fatta con il codice 1, non 3, come dovrebbe essere

 
Slawa:

Questo viene fatto nella build 1580

Prima di allora, la deinizializzazione era quasi sempre anticipata quando si cambiavano i tempi. Ma solo se l'interruttore del timeframe va giù, la deinizializzazione è stata fatta con il codice 1 e non 3 come dovrebbe essere


Allora come trattare questi codici di deinizializzazione in Inite dell'indicatore, cosa fanno questi codici? Poiché non c'è la possibilità di aspettare nell'indicatore, Sleep non funziona.