Sequenza di esecuzione di Init() e DeInit() - pagina 13
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
...
Diverse persone hanno già chiesto un esempio specifico di un compito che è problematico nel paradigma di esecuzione degli indicatori in MT5. Ci sarà o non ci sarà un esempio chiaro, non risucchiato dal nulla?
Un indicatore ha prima iniziale e poi deinit. Ma quando il timeframe viene cambiato, la seconda istanza dell'indicatore viene creata, e il suo init può essere eseguito prima del deinit dell'istanza precedente (non avviata).
L'esempio più ovvio - il salvataggio dei parametri utente quando si cambia l'orario - salviamo i parametri nel deinit, li leggiamo nell'init. Se l'init della nuova istanza è attivato prima del deinit dell'istanza precedente, i parametri non saranno salvati.
In pratica, il deinit dell'istanza rimossa è per lo più innescato prima dell'init della nuova istanza, ma se l'intervallo di tempo viene scambiato molto rapidamente o i dati vengono caricati, allora si verifica un fallimento.
E ora immaginate che non ci sia una sola coda di eventi, ma piuttosto una coda per ogni simbolo-periodo. Ci sono tanti periodi-simbolo quante sono le code.
Ora suggerite l'ordine in cui le code sono gestite.
Secondo me la coda dovrebbe essere legata a un grafico. Se l'utente cambia un simbolo, un TF o semplicemente lo chiude, tutti gli indicatori dovrebbero essere completamente finiti, quindi gli EA, con l'elaborazione di tutti i comandi nelle deinizioni (qualsiasi cosa facciano, scrivere in variabili globali, file, cancellare oggetti, interagire con DLL, inviare qualcosa a Internet) e dopo il completamento e lo scarico dalla memoria - eseguire nuove istanze su un nuovo TF o simbolo, senza sapere nulla del precedente, ma essendo in grado di leggere correttamente le informazioni salvate il precedente.
Probabilmente sarà un po' più lento, ma sarà la cosa giusta da fare.Sono a favore di programmi che funzionano correttamente, non veloci e sbagliati.
Se l'avvio della nuova istanza viene lanciato prima, allora si scopre che deinit non è affatto necessario ed è addirittura dannoso perché ingannerà i programmatori perché sperano che salvino qualcosa e poi lo contino. Se lo lasciamo così com'è, allora aggiungiamo all'aiuto - che i risultati di questa funzione non saranno noti al prossimo I risultati di questa funzione non saranno noti all'istanza successiva, cioè nessuno farà nulla in questa funzione. E ancora meglio - cancellatelo, se l'ordine naturale degli eventi è molto difficile da fare e vi richiederà centinaia di ore di lavoro.
Se il timeframe switch scende, allora prima OnInit sul timeframe inferiore (nuovo) e poi OnDeinit sul timeframe superiore (vecchio).
Se l'interruttore sale, è viceversa. Prima avviamo 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
Unalogica molto strana, cosa devo fare? Se ci saranno alcuni parametri scritti sul disco in DeInit, che dovrebbero essere letti e ripresi in OnInit durante il prossimo avvio dell'indicatore, anche se è avviato nel timeframe inferiore.
Credo di dover scrivere un breve test per verificarlo. Infatti, se la funzione passa a un timeframe inferiore, la logica andrà più che bene.
In generale, è un peccato che le variabili statiche non siano salvate negli indicatori, allo stesso tempo gli Expert Advisors sono ottimi con le statiche.1. Come si chiamano le applicazioni desktop? Ho la sensazione che MT5 non sia un'applicazione desktop...
2) Non me lo sto inventando. Questo è l'argomento del thread attuale. Il punto è che MT5 può eseguire Init per l'indicatore che non ha ancora DeInit. Sì, è così. Non hai letto l'argomento?
3.Prova ad aggiornare lo stesso file più volte al secondo e condividi le tue sensazioni.
4. Che cosa ha a che fare questo con l'aggiunta di 1 al nome? Si tratta del fatto che ci sono oggetti grafici dello stesso indicatore, ma copie diverse di esso, sullo schermo allo stesso tempo. Tecnicamente non c'è conflitto. Ci sarà un conflitto per l'utente che vede il cincischiare sullo schermo fino a quando la vecchia copia viene cancellata.
5. Lasciate che vi sveli un grande segreto: c'è una copia della DLL per ogni copia del terminale. Non è possibile utilizzarne più copie.1. Non stiamo parlando di MT5, stiamo parlando di indicatori (come script ed esperti) che non vengono eseguiti nel sistema operativo, ma in uno speciale ambiente sicuro.
2. Ti stai contraddicendo. Se il ricalcolo viene eseguito così rapidamente (diverse volte al secondo), allora non c'è nessun problema ad eseguire un nuovo ricalcolo in una nuova copia dell'indicatore. In questo caso ha senso resettare periodicamente i dati in esecuzione dopo un tempo stabilito (si può usare ontimer o un contatore personalizzato per questo). E se i calcoli sono lunghi, più è necessario salvare i dati dopo i calcoli per evitare la loro perdita in caso di forza maggiore (la mamma ha tolto la spina dalla presa "per evitare la fonazione").
3. La vecchia copia sarà cancellata in meno di un secondo, e con essa i suoi oggetti grafici. Che razza di imbecille commuterebbe TF con una frequenza tale da osservare lo sfarfallio? - E allora? Il dll non può essere rimosso dalla copia in meno di un secondo.
4. Allora, il dll può essere occupato, è normale. Non c'è da preoccuparsi, basta ripetere la richiesta in un secondo, per esempio.
Come potete vedere - nessun problema, dovete solo gestire correttamente i programmi nel terminale MT, ricordando che non sono applicazioni desktop e che girano in un ambiente speciale protetto.
Un indicatore ha prima iniziale e poi deinit. Ma quando il timeframe viene cambiato, la seconda istanza dell'indicatore viene creata, e il suo init può essere eseguito prima del deinit dell'istanza precedente (non avviata).
L'esempio più ovvio - il salvataggio dei parametri utente quando si cambia l'orario - salviamo i parametri nel deinit, li leggiamo nell'init. Se l'init della nuova istanza è attivato prima del deinit dell'istanza precedente, i parametri non saranno salvati.
In pratica, il deinit dell'istanza rimossa viene innescato prima dell'init della nuova istanza, ma se l'intervallo di tempo viene scambiato molto velocemente o i dati vengono caricati, si verifica un fallimento.
Ci risiamo... Perché "cambiare molto rapidamente i tempi"? Qualcuno di voi accende (o spegne) il computer "rapidamente premendo il pulsante" Power?
Perché? Lo proibisce il codice penale o la costituzione?
Perché? Lo proibisce il codice penale o la costituzione?
Ci sono molte cose che l'AC non vieta, come infilare le dita in una presa.
Dare un esempio della necessità di cambiare frequentemente il TF così velocemente che gli oggetti cominciano a sfarfallare. - Non dare un esempio dell'effetto ipnotico, perché può essere ottenuto con metodi più efficienti.
Ci sono molte cose che il regolatore non vieta, come infilare le dita in una presa.
Dare un esempio della necessità di cambiare il TF così spesso che gli oggetti cominciano a sfarfallare. - Non dare un esempio dell'effetto ipnotico, perché può essere ottenuto con metodi più efficienti.
Perché la presa e la spina sono state progettate da designer sensati, non da idioti. Sul lato della tensione c'è la presa, non la spina. Inoltre, i fori nella presa sono così grandi che non è possibile metterci il dito. Ma potete farlo a modo vostro in casa vostra: lasciate che le spine spuntino dal muro e le prese siano appese ai fili. Capite e non toccate con le mani le spine che sporgono dal muro.
OK. Le prese sono un esempio sfortunato.
Allora prendiamone un altro: saltare dal balcone! L'AC vieta di saltare dal balcone? - No? - Allora perché non lo pratichi per l'adrenalina?
Tutti gli obiettivi devono essere raggiunti con mezzi sensati, altrimenti gli obiettivi non sono sensati.
Andrey Dik:
Dare un esempio della necessità di cambiare frequentemente il TF così velocemente che gli oggetti cominciano a sfarfallare. - Non dare un esempio dell'effetto ipnotico, perché può essere ottenuto con metodi più efficienti.