Sequenza di esecuzione di Init() e DeInit() - pagina 6
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
Perché dovrebbero essere lenti? A meno che l'indicatore non sia scritto male. Un indicatore DeInit ben scritto richiede poco tempo. 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.
Ci sono diversi indicatori. Ci sono anche quelli lenti. E non tutti sono propri e in codice sorgente.
Sono divertito da un paio di secondi. Sento decine di millisecondi nell'interfaccia, sento subito il disagio.
E, soprattutto, non c'è risposta alla mia domanda:
In quali situazioni, tranne il lavoro diretto con oggetti grafici (senza il nome TF nel titolo), è importante la sequenza DeInit - Init?
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. Si possono sentire decine di millisecondi nell'interfaccia, c'è disagio subito.
E, soprattutto, non c'è una risposta alla mia domanda:
In quali situazioni, a parte il lavoro diretto con oggetti grafici (senza il nome TF nel nome), la sequenza DeInit - Init è importante?
Di solito non uso variabili globali, ma a volte succede.
Quando si lavora con le variabili globali ci si incasina. Quando si elimina l'indicatore dal grafico è necessario fare pulizia e cancellare le variabili globali. In quale punto dell'indicatore cancellerete le variabili globali? Probabilmente, dovrebbe essere cancellato in Deinite, non c'è altro posto. Così, quando si cambia l'orizzonte temporale e si creano nuove variabili, Deinite arriva e cancella tutto. Si scopre che le variabili globali non possono essere utilizzate negli indicatori.
Di solito non uso variabili globali, ma a volte succede.
Quando si lavora con le variabili globali, si diventa choppy. Quando rimuovi l'indicatore dal grafico, devi fare pulizia e rimuovere le variabili globali. In quale punto dell'indicatore cancellerete le variabili globali? Probabilmente, dovrebbe essere cancellato in Deinite, non c'è altro posto. Così, quando si cambia l'orizzonte temporale e si creano nuove variabili, Deinite arriva e cancella tutto. Si scopre che le variabili globali non possono essere utilizzate negli indicatori.
Sergiy, hai un esempio reale che non sia preso dal nulla? Posso anche inventarli, ma non ho affrontato alcun problema nella pratica.
Nota: le variabili globali possono anche essere nominate a seconda di TF.
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.
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 titolo), la sequenza DeInit - Init è importante?
A pagina 3 ho fatto un esempio pratico:
memorizzare nella testa del terminale ogni volta che le variabili rilevanti vengono cambiate, non quando ini/deinit.
ricordate nel terminale principale ogni volta che le variabili corrispondenti vengono cambiate, non quando ini/deinit.
Mi ricorderò)
E ricordate anche che nell'implementazione attuale non si può fare nulla in Deinit che poi deve essere usato (né in variabili globali né scrivendo su file)...
essenzialmente inutile finci è diventato, con una sequenza così interrotta.
Me ne ricorderò (meno male che mi sono imbattuto in questo thread per caso), ma altri programmatori (che non guarderanno qui) useranno la naturale conseguenza logica e useranno Deinit sperando che funzioni, e poi init verrà eseguito su un nuovo TF.
Mi ricorderò)
Ricorda anche che l'attuale implementazione del terminale non permette di fare nulla in Deinit che debba essere usato in seguito (né nelle variabili globali, né nei file)...
essenzialmente un finkzi inutile, con una sequenza così spezzata
Basta capire che c'è anche un'altra logica. La logica degli sviluppatori di MT in particolare. Secondo questa, altra logica, tutto sembra abbastanza logico. Da qui la conclusione: adattatevi a questa logica e non cercate di far cambiare idea a persone che probabilmente hanno più esperienza di voi in questo. È inutile... Nessuno accetterà di cambiare la logica stabilita per il bene di un indicatore.
Se non si trattasse di finanza, forse non ci sarebbe stata 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 potete fidarvi di lui per le vostre finanze?
Potremmo essere in disaccordo con gli sviluppatori di MT su questo argomento.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?
State confondendo un sacco di cose diverse. Mettiamoci d'accordo su almeno due requisiti per il terminale come software critico:
- deve funzionare in modo prevedibile, seguendo rigorosamente la stessa logica (anche con il multi-threading);
- deve funzionare rapidamente.
(non è importante se la copia dell'indicatore conosce altre copie, ma è importante che i dati globali, assegnati per la memorizzazione al terminale, siano coerenti - questa è la preoccupazione del terminale, non di ogni sviluppatore di indicatori)
Inoltre c'è una domanda - come implementarlo. Ora è implementato tenendo conto del requisito 2. Propongo di implementarlo tenendo conto del requisito 1, senza influenzare il requisito 2.
Non ci saranno rallentamenti evidenti, se facciamo attenzione al fatto che gli eventi di init/deinit del grafico e init/deinit dell'indicatore sono cose diverse. Il grafico mostrerà immediatamente il nuovo grafico principale, ma per gli indicatori legacy l'evento OnInit sarà accodato dopo l'elaborazione del precedente OnDeinit. Gli eventi sono comunque accodati nel terminale.
Se MQ desidera, può inviarmi alle sue condizioni i grafici NDA delle classi e delle sequenze, li correggerò ;-).