Sequenza di esecuzione di Init() e DeInit() - pagina 12
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
Ecco, i lamenti sono iniziati...
Quello che stai chiedendo è esattamente ciò che le normali applicazioni desktop non hanno.
Cosa non c'è nell'applicazione? Sincronizzazione? )))
Se gli sviluppatori non facessero tutte queste caratteristiche che sono già "out of the box", gli autori di programmi MQL affronterebbero costantemente tutti gli incanti dello sviluppo desktop, che si tratti di sicurezza o velocità di esecuzione.
1. Cosa non c'è nelle applicazioni? Sincronizzazione? )))
2) Lei sta facendo un ragionamento non scientifico senza fatti. In MT4, gli indicatori operano con successive OnInit() e DeInit(). C'è uno svantaggio: tutti gli indicatori lavorano in un unico thread. Può essere risolto scrivendo correttamente l'indicatore, che è richiesto anche in MT5. Anche se MT5 non ne ha fatto a meno - in ogni caso, gli indicatori di un grafico continuano a lavorare in un thread.1. di quale sincronizzazione stai parlando!
2. In MT4, come parte dell'esecuzione del codice dell'indicatore, viene prima eseguito init e poi deinit, che altro serve!!! È lo stesso in MT5.
Diverse persone mi hanno già chiesto di fare un esempio specifico di un compito che è problematico da eseguire all'interno del paradigma di esecuzione degli indicatori in MT5. Ci sarà un esempio o no, un esempio chiaro, non succhiato dal nulla?
1. Di quale sincronizzazione stai parlando?
Riguardo all'inter-threading. Finché un thread non si completa (quello a cui è stato dato il comando di terminare), l'altro thread non parte. Oppure, se tutto avviene in un thread, è ancora più semplice: terminare tutti i programmi associati al "vecchio" TF e solo allora avviare i programmi sul "nuovo" TF.
2. In MT4, come parte dell'esecuzione del codice dell'indicatore, viene prima eseguito init e poi deinit, di cos'altro avete bisogno? Lo stesso vale per MT5.
Giusto. Questo è esattamente il caso di MT4. Ma non è così in MT5. Ed è di questo che si tratta.
Diverse persone mi hanno già chiesto di fare un esempio specifico di un compito che è problematico da eseguire all'interno del paradigma di esecuzione degli indicatori in MT5. Ci sarà un esempio o no, un esempio chiaro, non succhiato dal nulla?
È 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?
Il sistema operativo si preoccupa che il TC non interferisca con gli altri TC e quello che fanno lì nella RAM, scambiare file o qualsiasi altra cosa sono affari loro.
"Credo di sì!" (c) Mimino, 1977.
Cosa c'entra Total Commander? È solo un'utilità di basso livello, nel senso che opera direttamente con le risorse del sistema. Nel caso di MQL, il compito della piattaforma MT è quello di liberare il programmatore dell'applicazione dalle cure del sistema come la sincronizzazione - la piattaforma può fornire questo in modo più efficace e in un colpo solo per tutti. I programmatori MQL devono pensare all'analisi delle quotazioni e alle strategie di trading. Questo è lo scopo della MT.
Cosa ha a che fare questo con lo scambio di file e dati? Considerate la logica del lavoro nel contesto di un programma MQL. Tenta semplicemente di usare gli eventi OnInit/OnDeinit secondo il loro scopo - per iniziare correttamente da un certo stato e terminare correttamente se stesso con il salvataggio dello stato. Se non sono adatti a questo scopo, allora, come già notato, a cosa servono? A giudicare dagli argomenti dei difensori - per poterci ballare dentro e scoprire quali altre copie sono state eseguite prima e dopo, e da quale periodo e a quale sono passate? Questo ha esattamente l'effetto opposto di quello che MQ voleva ottenere - che una copia non sa nulla dell'altra.
Affinché una copia non sappia nulla e non debba scoprirlo, e continui a lavorare senza effetti collaterali, il kernel ha bisogno di conoscere tutte le copie - sia quelle chiuse che quelle in avvio - e fornire una gestione aggraziata degli eventi init/deinit per loro in una metafora standard delle code. Il terminale traccia comunque tutte le copie e usa la coda degli eventi, ma per qualche ragione init/deinit rompe la logica degli eventi.
Affinchéuna copia non sappia nulla e non debba capirlo, e continui a lavorare senza effetti collaterali, il kernel deve essere consapevole di tutte le copie - sia quelle che vengono terminate che quelle che vengono avviate - e fornire una gestione aggraziata degli eventi init/deinit per loro nella metafora standard delle code. Il terminale tiene traccia di tutte le copie e usa la coda degli eventi, ma per qualche motivo init/deinit rompe la logica degli eventi.
Qual è il problema di memorizzare il periodo in una variabile principale?
Perché sarebbe necessario trasferire una matrice di dati tra successive esecuzioni dell'indicatore su TF diversi?
Andrey, non mi piacciono le variabili globali del terminale. Li ho sperimentati (molto tempo fa) e sono rimasto molto deluso dalla loro velocità e dalle difficoltà di sincronizzazione. Per evitare la mancanza di supporto cercherò di scrivere un esempio (un po' più tardi) che dimostri la loro velocità. Forse qualcosa è cambiato e mi sbaglio. Ma un'altra cosa che non mi piace delle variabili globali è che hanno una vita propria e sono assolutamente pubbliche. Tutti possono controllarli premendo F3 e cancellarli. Quando ce ne sono diversi, questo è metà del problema, ma se tutti cominciano a usarli, personalmente ho la sensazione di un casino sulla mia scrivania.
Riguardo al passaggio degli array. Sì, sono d'accordo, non è necessario molto spesso. Ma ecco un esempio specifico: il mio indicatore. Il suo funzionamento interno non dipende dal TF selezionato, perché durante l'inizializzazione scarica tutti (quasi tutti) i TF e crea il proprio array generale (qualcosa come un array logaritmico di quotazioni) ed esegue alcuni calcoli più voluminosi di array di indici basati su di esso. Quando si cambiano i TF, fare una e la stessa quantità di lavoro ogni volta non è affatto razionale - ci saranno dei ritardi quando si cambia TF. Ho anche nella mia testa degli algoritmi per il riconoscimento dei modelli, che implementerò, quindi lì i calcoli di inizializzazione possono richiedere fino a diversi secondi, e vorrei che accadesse solo una volta e dimenticarmene.
Affinché una copia non sappia nulla e non debba capirlo, e continui a lavorare senza effetti collaterali, il kernel deve essere consapevole di tutte le copie - sia quelle che vengono terminate che quelle che vengono avviate - e fornire una gestione aggraziata degli eventi init/deinit per loro nella metafora standard delle code. Il terminale traccia comunque tutte le copie e usa la coda degli eventi, ma per qualche ragione init/deinit rompe la logica degli eventi.
E ora immaginate che non ci sia un'unica coda di eventi, ma piuttosto una coda per ogni personaggio-periodo. Tanti personaggi-periodi, tante code.
Ora suggerite l'ordine in cui le code sono gestite.
E ora immaginate che non ci sia una sola coda di eventi, ma piuttosto una coda per ogni simbolo-periodo. Tanti periodi-simbolo quante sono le code.
Ora suggerite l'ordine in cui le code sono gestite.
1. sull'inter-threading. Finché un thread non si completa (quello a cui è stato dato il comando di terminare), l'altro thread non parte. Oppure, se tutto questo avviene in un thread, è ancora più semplice: terminiamo l'esecuzione di tutti i programmi connessi con il "vecchio" TF e solo dopo avviamo i programmi sul "nuovo" TF.
2. Giusto. È esattamente lo stesso in MT4. Ma non è così in MT5. Questo è l'argomento.
3. Ho dato lavora con oggetti grafici, nasce una bellezza: un indicatore esiste ancora e non è stato 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". )))1) Dovrebbe essere fatto come ho scritto prima: il database accumulato dovrebbe essere periodicamente salvato in un file o in un'altra memoria, nessun problema - aprire il file, scrivere, chiudere. Dovete farlo ogni volta che aggiornate questi dati o periodicamente, non ininit e deinit. (Si salva il lavoro periodicamente quando si scrive un programma, si scrive un articolo). Ed è impossibile assicurarsi contro il fallimento della scrittura su file, a volte per l'assicurazione in situazioni criticamente importanti fanno quanto segue: scrivono informazioni aggiornate in un nuovo file, dopo aver scritto con successo cancellano il vecchio, e cambiano il nome del nuovo file come era in quello vecchio.
2) L'ho già spiegato. Ogni indicatore deve lavorare con i propri oggetti grafici. Naturalmente, dobbiamo controllare l'esistenza degli oggetti e se esistono già, dobbiamo aggiungere 1 al nome dell'oggetto.
3) Beh, avete già scritto che è risolvibile.
E questi non sono affatto problemi. Questo è il normale funzionamento dei programmi - creazione di oggetti unici, salvataggio periodico delle informazioni accumulate, pulizia dopo il completamento.
1. questi sono i vostri desideri. Ma hai detto che volevi il modo in cui funzionano le app desktop, quindi il modo in cui vuoi le app desktop non funziona.
Come si chiamano le applicazioni desktop? Sembra che MT5 non sia un'applicazione desktop.
2. Non inventare storie. La sequenza di oninit e ondeinit è la stessa in MT4 e MT5. Non esiste un programma che inizi con deinit.
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) Ok, analizziamo gli esempi:
1) Fate come ho scritto prima: il database accumulato dovrebbe essere salvato periodicamente in un file o in un'altra memoria, nessun problema - aprire il file, scrivere, chiudere. Dovete farlo ogni volta che aggiornate questi dati o periodicamente, non ininit e deinit. (Si salva il lavoro periodicamente quando si scrive un programma, si scrive un articolo). Ed è impossibile assicurarsi contro il fallimento della scrittura su file, a volte per l'assicurazione in situazioni criticamente importanti fanno quanto segue: scrivono informazioni aggiornate in un nuovo file, dopo aver scritto con successo cancellano il vecchio, e cambiano il nome del nuovo file come era in quello vecchio.
Prova ad aggiornare lo stesso file più volte al secondo e condividi le tue sensazioni.
2) L'ho già spiegato. Ogni indicatore deve lavorare con i propri oggetti grafici. Naturalmente, dobbiamo controllare l'esistenza degli oggetti e se esistono già, dobbiamo aggiungere 1 al nome dell'oggetto.
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.
3) Beh, avete già scritto che è risolvibile.
Questo non è affatto un problema. Questo è il normale funzionamento del programma - creazione di oggetti unici, salvataggio periodico delle informazioni accumulate, pulizia dopo il completamento.