Sequenza di esecuzione di Init() e DeInit() - pagina 10
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
Ho scritto chiaramente - tenete sempre aggiornati i dati che dovete trasferire alla copia, non dovete farlo solo quando siete initis, teneteli sempre aggiornati.
Andrey, stai scherzando o davvero non capisci che tutti i tuoi dati reali memorizzati nelle variabili e negli array negli indicatori diventano irrilevanti dopo il cambio di TF perché la copia dell'indicatore con tutti i suoi dettagli viene cancellata. In Expert Advisors, naturalmente, tutto è semplice, perché non c'è reinizializzazione.
Stai scherzando o non capisci che tutti i tuoi dati reali memorizzati nelle variabili e negli array negli indicatori diventano irrilevanti dopo il cambio di TF perché la copia dell'indicatore con tutti i suoi dettagli viene cancellata. In Experts, naturalmente, tutto è semplice, perché non c'è reinizializzazione.
No, non lo sono.
Non capisci quello che sto dicendo.
Per esempio, c'è un certo insieme di dati che deve essere trasferito a un'altra copia dell'indicatore (che sia un altro indicatore gettato su un grafico o una nuova copia dell'indicatore quando cambia il TF, non importa). L'indicatore calcola qualcosa e ogni volta che calcola qualcosa e questo qualcosa sarà applicato ad altri indicatori, questo indicatore dovrebbe aggiornarsi. Ogni volta. Questo database può essere memorizzato in diversi luoghi, a seconda della quantità di dati e della velocità di comunicazione richiesta. Questi dati devono essere aggiornati ogni volta che è necessario dopo una modifica dei dati, non solo quando vengono deinizializzati. Questo è il trucco. Non c'è niente di complicato. Non si tratta di memorizzare i dati nelle variabili locali dell'indicatore, ma di resettare/aggiornare i dati ogni volta che i dati sono stati ricalcolati.
Ma con gli oggetti grafici è molto semplice.
In Expert Advisors, naturalmente, tutto è semplice, perché non c'è reinizializzazione.
No, non lo sono.
Non capisci quello che sto dicendo.
Per esempio, c'è un certo insieme di dati che deve essere trasferito a un'altra copia dell'indicatore (che sia un altro indicatore gettato su un grafico o una nuova copia dell'indicatore quando cambia il TF, non importa). L'indicatore calcola qualcosa e ogni volta che calcola qualcosa e questo qualcosa sarà applicato ad altri indicatori, questo indicatore dovrebbe aggiornarsi. Ogni volta. Questo database può essere memorizzato in diversi luoghi, a seconda della quantità di dati e della velocità di comunicazione richiesta. Questi dati devono essere aggiornati ogni volta che è necessario dopo una modifica dei dati, non solo quando vengono deinizializzati. Questo è il trucco. Non c'è niente di complicato. Non si tratta di memorizzare i dati nelle variabili locali dell'indicatore, ma di reimpostare/aggiornare i dati ogni volta che i dati sono stati ricalcolati.
E con gli oggetti grafici è abbastanza semplice, non c'è nemmeno bisogno di spiegare.
È molto discutibile che nulla sia complicato. Provate a replicare realmente sull'esempio di una semplice macchina ondulatrice quello che ho implementato in questo prodotto. Nella ruota da polso si cambia il periodo con il mouse e poi, quando si cambia TF, le modifiche dovrebbero essere salvate, e si possono usare diversi indicatori nella finestra. E vedrete che non c'è niente di complicato. E se avete bisogno di passare un array E vedrete quanto è "semplice". Forse lo penserei anch'io, se non l'avessi già attuato.
È molto discutibile che niente sia difficile. Cercate di replicare realmente sull'esempio di un semplice demolitore quello che ho implementato in questo prodotto. Nella ruota da polso si cambia il periodo con il mouse, e poi, quando si cambia TF, le modifiche dovrebbero essere salvate, ed è possibile utilizzare diversi indicatori nella finestra. E vedrete che non c'è niente di complicato. E se avete bisogno di passare un array E vedrete quanto è "semplice".
Ho imparato solo recentemente che tutte le variabili negli EA sono conservate durante la reinizializzazione, cioè ho scritto gli EA allo stesso modo degli indicatori, supponendo che il programma non sappia nulla degli altri programmi, perché c'è solo il loro init e deinit, il programma non deve sapere degli init e deinit degli altri programmi.
È per questo che non faccio mai affidamento sulla coerenza temporale dell'ininit e del deinit del programma da scaricare ed eseguire di nuovo, non facevo mai affidamento sul fatto che può cambiare qualche volta (nel 1580 è cambiato). Affidarsi a bug non documentati e a future piattaforme può ritorcersi contro in futuro.
Nella mia pratica, ci sono anche prodotti che cambiano dinamicamente la visualizzazione a seconda delle azioni dell'utente, applicando tutto, dagli eventi ai file di scambio. Ci sono molti più indicatori sul grafico di 1 come regola, i buffer degli indicatori in 5 sono illimitati e si possono creare come parametro durante l'avvio. Cioè noi siamo persone creative, dobbiamo avere un approccio flessibile per risolvere i nostri compiti e allo stesso tempo tenere a mente le specificità di 3 tipi di programmi, ma gli sviluppatori di piattaforme si preoccupano di altre questioni, che sono più importanti delle difficoltà minori rispetto ai compiti globali della piattaforma.
Ci sono difetti davvero importanti nella piattaforma, di cui non parlano molto o per niente, è molto più importante del problema inverosimile degli "inits e deinserts".
Se il timeframe viene commutato verso il basso, OnInit sul timeframe più basso (nuovo) prima 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 più basso al più alto lasso di tempo
Questo è semplicemente terribile. I programmatori di applicazioni non devono pensare a queste cose sistematiche. La piattaforma può gestire le cache internamente come vuole, ma a livello di MQL deve portare tutto in modo trasparente in un unico contratto di eventi, senza potenziali effetti collaterali. Tutti i riferimenti a presunte considerazioni di efficienza e alla possibilità per tutti di aggirare il problema da soli sono semplicemente insostenibili. È possibile fare entrambe le cose in modo efficace e conveniente (eliminando del tutto la possibilità di calpestare questo rastrello), una volta per tutte.
È vero, non dovrebbero. Così si esegue Total Commander, per esempio. Perché pretendere da Microsoft che Windows si occupi della "corretta" sequenza di caricamento/scaricamento delle copie TC nella RAM? È una preoccupazione del sistema operativo?
La preoccupazione del SO è che il TC non interferisca con gli altri TC e quello che fanno lì in RAM, scambiarsi file o qualsiasi altra cosa sono affari loro.
"Penso di sì!" (c) Mimino, 1977.
Vorrei sintetizzare e riassumere quanto sopra. Quindi, prima del rilascio della build 1580 di MT5 (attuale build 1571), cosa abbiamo?
Negli indicatori, a differenza degli Expert Advisors, quando cambia il TF, poiché"viene creata una nuova copia dell'indicatore, che non sa nulla della copia precedente", tutte le variabili vengono reinizializzate, inoltre l'ordine di esecuzione di OnDeinit del vecchio TF e OnInit del nuovo TF è imprevedibile, indipendentemente dal fatto che il TF sia "su" o "giù" (pratica, contrariamente a quanto detto da Mr. Slava). A questo proposito i programmatori hanno una serie di problemi e incertezze. Per esempio:
- il programmatore, che non ha letto questo argomento, crea un oggetto per qualcosa in OnInit, ed è logico controllare l'esistenza dell'oggetto con questo nome prima di crearlo. Inoltre è logico prescrivere la rimozione di questo oggetto in OnDeinit. Quando TF viene cambiato, se viene eseguito il primo OnInit del nuovo TF, controlla l'esistenza dell'oggetto, risulta che esiste già, e non viene creato, perché è già creato. Poi viene eseguito OnDeinit del vecchio TF e l'oggetto viene rimosso. Il programmatore è in uno stato di shock. Dov'è il mio oggetto e perché è sparito? Sarà ancora più confuso, quando la prossima volta che il TF viene cambiato, quando la sequenza di OnInit e OnDeinit è diversa, l'oggetto non viene rimosso. È cancellato, non è cancellato.... Dopo una lunga ricerca inizierà a rivolgersi al Service Desk, nuovi argomenti sul forum sul vecchio.
Questa è solo la situazione più semplice. Ce ne saranno altri perché questa caratteristica non è descritta nella documentazione e si può solo leggere sul forum.
Se volete creare qualcosa di speciale e passare alcuni parametri dalla vecchia copia dell'indicatore alla nuova, quando cambiate il TF, non potete usare OnDeinit, a causa della sequenza imprevedibile delle operazioni di inizializzazione e deinizializzazione. Secondo me, la soluzione migliore in questo caso è usare i seguenti strumenti:ResourceCreate basato sull'array di pixel eResourceReadImage, ma è abbastanza macchinoso e bisogna occuparsi del conflitto di risorse, se si usano diversi indicatori identici in una finestra, e ogni volta i dati che si vogliono inviare per un'altra copia devono essere salvati in una risorsa non reinizializzata, perché il tempo del possibile cambiamento di TF non è noto all'applicazione. Ho implementato questo molto tempo fa (ad esempio in questo prodotto), quindi so di cosa sto parlando. L'implementazione del trasferimento di dati attraverso file e variabili globali del terminale è una soluzione meno riuscita (IMHO).
Se la nuova build 1580 saràcome dice Slava, non renderà il compito più facile, perché la deinizializzazione della vecchia copia dell'indicatore avverrà dopo l'inizializzazione di una nuova. Ma non ci sarà alcuna incertezza.
Dobbiamo sperare che gli sviluppatori abbiano prestato attenzione a questo problema, dato che stanno cercando di risolverlo.
Siamo in attesa di una nuova costruzione.
Sono completamente d'accordo che questa caratteristica di elaborazione DEVE essere menzionata nella documentazione, altrimenti i nuovi arrivati si troveranno di fronte a questo problema e verranno nei forum a cercare una soluzione. (Perché, quando puoi dirglielo subito nel Terminale e nei documenti MQL).
Aggiungete anche alla documentazione che il log non mostra un quadro completo degli eventi, ma solo una parte di esso. Vedere i registri completi per un quadro completo.
Circa il resto più tardi ...
Vorrei sintetizzare e riassumere quanto sopra. Quindi, prima del rilascio della build 1580 di MT5 (attuale build 1571), cosa abbiamo?
Negli indicatori, a differenza degli Expert Advisors, quando cambia il TF, poiché"viene creata una nuova copia dell'indicatore, che non sa nulla della copia precedente", tutte le variabili vengono reinizializzate, inoltre l'ordine di esecuzione di OnDeinit del vecchio TF e OnInit del nuovo TF è imprevedibile, indipendentemente dal fatto che il TF sia "su" o "giù" (pratica, contrariamente a quanto detto da Mr. Slava). A questo proposito i programmatori hanno una serie di problemi e incertezze. Per esempio:
- il programmatore, che non ha letto questo argomento, crea un oggetto per qualcosa in OnInit, ed è logico controllare l'esistenza dell'oggetto con questo nome prima di crearlo. Inoltre è logico prescrivere la rimozione di questo oggetto in OnDeinit. Quando TF viene cambiato, se viene eseguito il primo OnInit del nuovo TF, controlla l'esistenza dell'oggetto, risulta che esiste già, e non viene creato, perché è già creato. Poi viene eseguito OnDeinit del vecchio TF e l'oggetto viene rimosso. Il programmatore è in uno stato di shock. Dov'è il mio oggetto e perché è sparito? Sarà ancora più confuso, quando la prossima volta che il TF viene cambiato, quando la sequenza di OnInit e OnDeinit è diversa, l'oggetto non viene rimosso. È cancellato, non è cancellato.... Dopo una lunga ricerca inizierà a rivolgersi al Service Desk, nuovi thread sul forum sul vecchio.
Questa è solo la situazione più semplice. Ce ne saranno altri, dato che questa caratteristica non è descritta nella documentazione e si può solo leggere sul forum.
Se volete creare qualcosa di speciale e passare alcuni parametri dalla vecchia copia dell'indicatore alla nuova, quando cambiate il TF, non potete usare OnDeinit, a causa della sequenza imprevedibile delle operazioni di inizializzazione e deinizializzazione. Secondo me, la soluzione migliore in questo caso è usare i seguenti strumenti:ResourceCreate basato sull'array di pixel eResourceReadImage, ma è abbastanza macchinoso e bisogna occuparsi del conflitto di risorse, se si usano diversi indicatori identici in una finestra, e ogni volta i dati che si vogliono inviare per un'altra copia devono essere salvati in una risorsa non reinizializzata, perché il tempo del possibile cambiamento di TF non è noto all'applicazione. Ho implementato questo molto tempo fa (ad esempio in questo prodotto), quindi so di cosa sto parlando. L'implementazione del trasferimento di dati attraverso file e variabili globali del terminale è una soluzione meno riuscita (IMHO).
Se la nuova build 1580 saràcome dice Slava, non renderà il compito più facile, perché la deinizializzazione della vecchia copia dell'indicatore sarà eseguita dopo l'inizializzazione di una nuova. Ma almeno non ci saranno incertezze.
Spero che gli sviluppatori abbiano prestato attenzione a questo problema, dato che cercano di risolverlo.
Siamo in attesa di una nuova costruzione.
L'Expert Advisor funziona bene quando si cambia il TF, mentre l'indicatore in questa situazione funziona in modo molto diverso.
Nessun problema se siete consapevoli di questa caratteristica non documentata e vi occupate solo del caso più semplice: il grafico. oggetti. Voglio dire che coloro che non conoscono questa caratteristica, penso che questo argomento su questo forum sarà letto da una percentuale molto piccola di programmatori e mi dispiace solo il loro tempo per capire tutte le sfumature. Mi sono trovato in questa situazione prima di capirne l'essenza.