Sequenza di esecuzione di Init() e DeInit() - pagina 9
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
Grazie per il codice, naturalmente. Ma gli EA vanno bene in ogni caso perchéquando cambio TF non reinizializzano le variabili, mentre gli indicatori sì. Se vuoi davvero aiutare con un consiglio, per favore "eseguilo" di nuovo con meno fretta.
Nicholas, mi sono imbattuto nell'argomento, anche quando ho scritto il primo post. E non ho trovato nessuna discussione su come un EA si comporta quando il timeframe cambia. Sì - l'argomento è principalmente sugli indicatori, mentre l'autore ha scritto nel suo post"Un indicatore o Expert Advisorè scritto ".
Ho dato un esempio che ho controllato e che funziona nell'ambito dell'Expert Advisor. Ma tu - poi mi rimproveri la disattenzione, poi mi mandi a rileggere l'argomento, poi discuti - cosa è ragionevole o non ragionevole. Inoltre, potete leggere la prima pagina
Non è chiaro se stai parlando di un Expert Advisor o di un indicatore. Non dici nemmeno chiaramente nel tuo post che stai parlando di un indicatore.
VEDERE UN ESEMPIO DEL TUO POST:
Allora, è tutto?
Ho sperimentato e usato questo codice di ragione (REASON_CHARTCHANGE) al massimo. Ma a cosa serve se tutte le variabili sono impostate al loro stato iniziale e OnDeinit viene eseguito dopo OnInit del nuovo TF?
È chiaro da quello che ho appena detto che le variabili sono inizializzate nell'indicatore?
La persona che legge il tuo post potrebbe pensare che la stessa cosa accade in un Expert Advisor.
----
La risposta a questa domanda è: "Quando si cambia TF, la reinizializzazione delle variabili non avviene, mentre avviene negli indicatori".
si possono salvare i valori delle variabili da qualche parte, nei globali per esempio...
Se volete usare questa funzione in qualche altro modo, dovete usare OnInit per leggere e ripristinare i valori.
------------
Se sei interessato solo al problema di cambiare il TF per l'indicatore - non significa che altri, me compreso, non siano interessati all'opzione di cambiare il TF per l'EA.
Non possodare consigli sull'indicatore, perché non so come farlo in pratica, ma osserverò con interesse le soluzioni suggerite.
Ho capito che gli sviluppatori stanno leggendo questo argomento e hanno anche corretto alcune cose nella build 1580. Forse offriranno delle soluzioni.
Non hai letto più volte quello che ho scritto?
Non c'è modo negli indicatori. Non si può fare in cinque dall'inizio. Perché devi scaricare una copia completamente nuova dell'indicatore con tutte le sue conseguenze.
Grazie per la sua risposta onesta.
È sempre stato così in 5. Forse è il momento di ripararlo?
È davvero così difficile fare l'ordine giusto? Risparmiare tempo all'inizio si traduce poi in controlli infiniti ad ogni spunta.
Mi sono già abituato al paradigma OOP di MT5 e so dove si trova il rastrellamento e come fissare le stampelle per aggirare questi rastrellamenti, naturalmente se non ce ne sono di nuovi. Si scopre che è più facile cancellare un oggetto e crearne uno nuovo che cambiare un paio di parametri.
Allo stesso modo, in una macchina, invece di cambiare l'olio e continuare a guidare, è meglio buttare via la macchina e farne una nuova.
Mi ricorda un cartone animato:
Puoi dirmelo per favore?
Ho deciso di scrivere un programma che
1. Su Inite uscite 8 linee
2. Su DeInite escono altre 8 linee.
L'ho eseguito nel tester (l'ho eseguito per 2 giorni e l'ho ottenuto).
Per qualche motivo, non riesce selettivamente a registrare alcune linee.
Anche questo è per accelerare le cose?
------------------------------------------------------------------------------------------
DOMANDA RIMOSSA PERCHÉ I REGISTRI COMPLETI HANNO TUTTE LE INFORMAZIONI
------------------------------------------------------------------------------------------
Nella documentazione è necessario aggiungere
1. Il registro non mostra tutte le informazioni che il programmatore si aspetta
-------- È ESSENZIALE VEDERE IL REGISTRO COMPLETO!!!
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, controllando logicamente prima della creazione dell'indicatore l'esistenza di un oggetto con questo nome. 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 non ci sarà alcuna incertezza.
Spero che gli sviluppatori abbiano prestato attenzione a questo problema, dato che stanno cercando di risolvere qualcosa.
Aspettiamo la nuova costruzione.
Tutti gli oggetti del grafico sono nominati con riferimento alla TF corrente. Quando si inizializza, crea, quando si deinizializza, cancella. Durante il funzionamento dell'indicatore si modifica secondo le necessità.
C'è un problema qui? Nessun problema. Tutto è normale dal momento dell'avvio dell'indicatore fino al momento del suo scarico.
Passiamo al TF. Non importa da che parte vada, su o giù. Viene lanciata una copia dell'indicatore. Questo equivale al fatto che l'indicatore è stato lanciato per la prima volta su questo TF.
C'è un problema qui? Non c'è nessun problema. La vecchia copia si occuperà di rimuovere i suoi oggetti, e la nuova copia ne creerà di nuovi in base al tempo corrente.
Cosa sto facendo di sbagliato? Perché non vedo un problema?
Tutti gli oggetti del grafico sono nominati con riferimento alla TF corrente. Quando si inizializza, crea, quando si deinizializza, cancella. Durante il funzionamento dell'indicatore si modifica secondo le necessità.
C'è un problema qui? Nessun problema. Tutto è normale dal momento dell'avvio dell'indicatore fino al momento del suo scarico.
Passiamo al TF. Non importa da che parte vada, su o giù. Viene lanciata una copia dell'indicatore. Questo equivale al fatto che l'indicatore è stato lanciato per la prima volta su questo TF.
C'è un problema qui? Non c'è nessun problema. La vecchia copia si occuperà di rimuovere i suoi oggetti, e la nuova copia ne creerà di nuovi in base al tempo corrente.
Cosa sto facendo di sbagliato? Perché non vedo un problema?
Nessun problema se siete consapevoli di questa caratteristica non documentata e vi occupate solo del caso più semplice - con il grafico. oggetti. Voglio dire che coloro che non conoscono questa caratteristica, penso che questo argomento sia letto da una percentuale molto piccola di programmatori su questo forum, e mi fa solo pena il loro tempo per capire tutte le sfumature. Mi sono trovato in questa situazione prima di capirne l'essenza.
Non ho mai sentito parlare di sfumature come quelle descritte in questo thread, ma non ho mai incontrato problemi come quelli descritti qui.
se volete trasferire qualcosa ad un'altra copia dell'indicatore, non avete bisogno di farlo deinit - mantenete i dati trasferiti aggiornati durante tutta la vita dell'indicatore - per esempio nelle variabili principali del terminale, quindi non importa il motivo dello scarico dell'indicatore (cambiamento di TF, mia madre ha staccato la spina "così non ronzerà quando tutti dormono", terremoto, cambiamento dei poli magnetici terrestri e così via.ecc.) la prossima esecuzione dell'indicatore (compresa una copia quando il TF cambia) otterrà tutte le informazioni necessarie da questa magica fonte di dati (per i casi sfortunati di scala globale è possibile mantenere i dati su un disco cloud).
Ragazzi, non c'è nessun problema.
Tutti gli oggetti del grafico sono nominati con riferimento alla TF corrente. All'inizializzazione creiamo, alla deinizializzazione cancelliamo. Durante il funzionamento dell'indicatore modificare come necessario.
C'è un problema qui? Nessun problema. Tutto è normale dal momento dell'avvio dell'indicatore fino al momento del suo scarico.
Passiamo al TF. Non importa da che parte vada, su o giù. Viene lanciata una copia dell'indicatore. Questo equivale al fatto che l'indicatore è stato lanciato per la prima volta su questo TF.
C'è un problema qui? Non c'è nessun problema.
C'è un problema: l'esistenza simultanea di oggetti di diversi indicatori. "Spiacenti, abbiamo problemi tecnici temporanei" (ma questo sarà risolto in pochi secondi quando avverrà il DeInit del vecchio indicatore)
La vecchia copia si occuperà di rimuovere i suoi oggetti, e la nuova copia creerà i suoi nuovi, nominandoli secondo l'attuale TF.
Cosa sto facendo di sbagliato? Perché non vedo alcun problema?
È una visione ristretta. Ecco perché non puoi vedere. Allarga un po' i tuoi orizzonti. I primi problemi si verificano mentre si lavora con i file, poiché non è chiaro se l'indicatore precedente è già riuscito a salvare i dati nel file o non ancora. Si dovranno creare alcuni flag nelle variabili globali del terminale. La nuova copia dell'indicatore dovrà aspettare che la vecchia copia resetti i dati accumulati. A proposito, il problema è che tale sincronizzazione è possibile solo in OnCalculate(). E cosa fare se lo scambio avviene durante il fine settimana? Una nuova copia non inizierà prima di lunedì? Oh, sì, possiamo metterlo su un timer! Ho sentito che si può sparare ai passeri con un cannone, la fionda sarebbe un bel modo di andare.
Questi sono ancora problemi semplici. Cercate di tenere conto di questa logica quando lavorate con DLL multi-thread. Ora è qui che inizia il divertimento. Beh, diventeremo più forti ))))
Non ho mai sentito parlare di sfumature come quelle descritte in questo thread, ma non ho mai incontrato alcun problema con i problemi descritti qui.
se volete trasferire qualcosa ad un'altra copia dell'indicatore, non avete bisogno di farlo deinit - mantenete i dati trasferiti aggiornati durante tutta la vita dell'indicatore - per esempio nelle variabili principali del terminale, quindi non importa il motivo dello scarico dell'indicatore (cambiamento di TF, mia madre ha staccato la spina "così non ronzerà quando tutti dormono", terremoto, cambiamento dei poli magnetici terrestri e così via.ecc.) il prossimo lancio dell'indicatore (inclusa la copia al cambio di TF) otterrà tutte le informazioni necessarie da questa magica fonte di dati (per i casi sfortunati di scala globale è possibile mantenere i dati sul disco cloud).
Ragazzi, non c'è nessun problema.
C'è un problema: l'esistenza simultanea di oggetti di diversi indicatori. "Spiacenti, abbiamo problemi tecnici temporanei" (ma saranno risolti in pochi secondi, quando avverrà il DeInit del vecchio indicatore)
Un campo visivo ristretto. Ecco perché non puoi vedere. Allarga un po' i tuoi orizzonti. I primi problemi appaiono quando si lavora con i file, perché non è chiaro se l'indicatore precedente ha già resettato i dati nel file o no. Si dovranno creare alcuni flag nelle variabili globali del terminale. La nuova copia dell'indicatore dovrà aspettare che la vecchia copia resetti i dati accumulati. A proposito, il problema è che tale sincronizzazione è possibile solo in OnCalculate(). E cosa fare se lo scambio avviene durante il fine settimana? Una nuova copia non inizierà prima di lunedì? Oh, sì, possiamo metterlo su un timer! Ho sentito che si può sparare ai passeri con un cannone, la fionda sarebbe un bel modo di andare.
Questi sono ancora problemi semplici. Cercate di tenere conto di questa logica quando lavorate con DLL multi-thread. Ora è qui che inizia il divertimento. Beh, diventeremo più forti)))
L'ho scritto molto chiaramente: tieni sempre aggiornati i dati che ti servono per copiare. Non devi farlo solo quando li usi, devi tenerli sempre aggiornati.
Tutti gli altri casi sono inventati a causa di una certa irritabilità.
Se c'è un problema con l'esecuzione dello stesso indicatore allo stesso tempo, allora create ogni volta oggetti unici con un collegamento al TF e se ci sono già oggetti aggiungete 1 al nome.
Nessuno ha citato un solo caso in cui i problemi sono insormontabili a causa del modo attuale in cui il terminale funziona con gli indicatori. I problemi sono causati da un lavoro errato con gli indicatori.
In generale, molte persone non sembrano capire che ci sono 3 tipi di programmi per una ragione (il 4° sarà disponibile presto).