Seqüência de execução Init() e DeInit() - página 13
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
...
Várias pessoas já pediram um exemplo específico de uma tarefa que é problemática dentro do paradigma de execução de indicadores no MT5. Haverá ou não um exemplo claro, não será sugado do nada?
Um indicador tem primeiro a inicial e depois o deinit. Mas quando o cronograma é trocado, a segunda instância indicadora é criada e seu init pode ser executado antes do deinit da instância anterior (não cartografada).
O exemplo mais óbvio - a economia dos parâmetros do usuário ao mudar o período de tempo - salvamos os parâmetros no deinit, lemos os parâmetros no init. Se o init da nova instância for acionado antes do deinit da instância anterior, os parâmetros não serão salvos.
Praticamente, o deinit da instância apagada é acionado principalmente antes do init da nova instância, mas se o prazo é trocado muito rapidamente ou se os dados são carregados, então ocorre uma falha.
E agora imagine que não há uma única fila de eventos, mas sim uma fila para cada período de símbolo. Há tantos períodos-símbolo quanto filas de espera.
Agora sugira a ordem na qual as filas são tratadas.
Na minha opinião, a fila deveria estar ligada a um gráfico. Se o usuário muda um símbolo, TF ou simplesmente o fecha, todos os indicadores devem estar completamente terminados, depois os EAs, com processamento de todos os comandos em deinitions (o que quer que eles façam, escrevendo para variáveis globais, arquivos, apagando objetos, interagindo com DLL, enviando algo para a Internet) e após a conclusão e descarregamento da memória - executar novas instâncias em um novo TF ou símbolo, sem saber nada sobre o anterior, mas podendo ler corretamente as informações salvas no anterior.
Provavelmente será um pouco mais lento, mas será a coisa certa a fazer.Eu sou a favor de programas que funcionem corretamente, não rápidos e errados.
Se o início da nova instância é lançado mais cedo, então acontece que o deinit não é necessário e é até prejudicial, porque vai enganar os programadores, pois eles esperam que eles salve algo e depois o contem. Se deixarmos as coisas como estão, então acrescente à ajuda - que os resultados desta função não serão conhecidos para o próximo Os resultados desta função não serão conhecidos para a próxima instância, ou seja, ninguém fará nada nesta função. E melhor ainda - apague-o, se a ordem natural dos eventos for muito difícil de fazer e exigir centenas de horas de trabalho.
Se a chave de tempo cair, então primeiro OnInit no menor (novo) tempo e depois OnDeinit no maior (antigo) tempo.
Se o interruptor subir, é o inverso. Primeiro começamos o OnDeinit no menor (antigo) período de tempo e depois o OnInit no maior (novo) período de tempo.
Aqui devemos ter em mente que as caches são processadas desde o menor até o maior prazo
Uma lógica muito estranha! O que devo fazer? Se houver alguns parâmetros escritos no DeInit no disco, que devem ser lidos e pegos no OnInit durante o próximo início do indicador, mesmo que ele seja iniciado no período de tempo mais baixo.
Acho que preciso escrever um pequeno teste para verificá-lo. De fato, se a função mudar para um período de tempo menor, a lógica será mais do que boa.
Em geral, é uma pena que as variáveis estáticas não sejam salvas nos indicadores, ao mesmo tempo em que os Expert Advisors são ótimos com a estática.1. O que você chama de aplicações desktop? Tenho a sensação de que o MT5 não é uma aplicação desktop.
2) Eu não estou inventando isso. Este é o tópico da linha atual. A questão é que o MT5 pode executar o Init para o indicador que ainda não tenha o DeInit. Sim, é. Você ainda não leu o tópico?
3.Tente atualizar o mesmo arquivo várias vezes por segundo e compartilhe seus sentimentos.
4. O que isso tem a ver com a adição de 1 ao nome? Trata-se do fato de que existem objetos gráficos do mesmo indicador, mas com cópias diferentes, na tela ao mesmo tempo. Tecnicamente, não há conflito. Haverá um conflito para o usuário que vê a decepção na tela até que a cópia antiga seja apagada.
5. Deixe-me contar-lhe um grande segredo: há uma cópia da DLL por cópia terminal. Você não pode usar várias cópias delas.1. Não estamos falando do MT5, estamos falando de indicadores (como scripts e especialistas) que não são executados no sistema operacional, mas em um ambiente especial de segurança.
2. Você está se contradizendo. Se o recálculo for realizado tão rapidamente (várias vezes por segundo), então não há problema para realizar um novo recálculo em uma nova cópia do indicador. Neste caso, faz sentido reiniciar os dados em execução periodicamente após um tempo definido (você pode usar o temporizador ou o contador personalizado para isso). E se os cálculos forem longos, mais é necessário salvar os dados após os cálculos para evitar sua perda em caso de força maior (a mãe retirou o plugue da tomada "para evitar a fonação").
3. A cópia antiga será apagada em menos de um segundo, e com ela seus grafetos. Que tipo de idiota trocaria o TF com uma freqüência tal que a cintilação fosse observada? - E daí? A dll não pode ser retirada da cópia em menos de um segundo.
4. então? a dll pode estar ocupada, é normal. Você não precisa se preocupar com isso; basta repetir o pedido em um segundo, por exemplo.
Como você pode ver - sem problemas, você só precisa manusear os programas no terminal MT corretamente, lembrando que eles não são aplicações desktop e que eles rodam em um ambiente protegido especial.
Um indicador tem primeiro a inicial e depois o deinit. Mas quando o cronograma é trocado, a segunda instância indicadora é criada e seu init pode ser executado antes do deinit da instância anterior (não cartografada).
O exemplo mais óbvio - a economia dos parâmetros do usuário ao mudar o período de tempo - salvamos os parâmetros no deinit, lemos os parâmetros no init. Se o init da nova instância for acionado antes do deinit da instância anterior, os parâmetros não serão salvos.
Praticamente, o deinit da instância removida é acionado antes do init da nova instância, mas se o prazo for trocado muito rapidamente ou se os dados forem carregados, ocorre uma falha.
Aqui vamos nós novamente... Por que "mudar os prazos muito rapidamente"?! Algum de vocês liga (ou desliga) seu computador "rapidamente pressionando o botão" Ligar?
Por quê? O código penal o proíbe ou a constituição?
Por quê? O código penal o proíbe ou a constituição?
Há muitas coisas que o ar condicionado não proíbe, como enfiar seus dedos em uma tomada.
Dê um exemplo da necessidade de troca frequente do TF tão rápido que os objetos começam a cintilar. - Não dê um exemplo do efeito hipnótico, pois ele pode ser alcançado por métodos mais eficientes.
Há muitas coisas que o regulador não proíbe, como enfiar seus dedos em uma tomada.
Dê um exemplo da necessidade de trocar o TF tão freqüentemente que os objetos começam a cintilar. - Não dê um exemplo do efeito hipnótico, pois ele pode ser alcançado por métodos mais eficientes.
Porque a tomada e o plugue foram projetados por designers sensatos, não por idiotas. No lado da voltagem está a tomada, não o plugue. Além disso, os buracos na tomada são tão grandes que você não pode colocar o dedo lá dentro. Mas você pode fazer do seu jeito em sua própria casa - deixe os plugues saírem da parede e as tomadas penduradas nos fios. Você entende e não toca com as mãos os plugues salientes da parede.
OK. Os soquetes são um exemplo infeliz.
Então vamos levar outro - pulando da varanda! O ar condicionado proíbe saltar da varanda? - Não? - Então por que você não o pratica para fins de adrenalina?
Todas as metas devem ser alcançadas por meios sensatos, caso contrário, as metas não são sensatas.
Andrey Dik:
Dê um exemplo da necessidade de trocar o TF freqüentemente tão rápido que os objetos começam a cintilar. - Não dê um exemplo do efeito hipnótico, pois ele pode ser alcançado por métodos mais eficientes.