Seqüência de execução Init() e DeInit() - página 5
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
Eu entendo isso. Eu estava perguntando sobre a lógica da seqüência de operações. E aqui estamos perdendo isso. Algumas vezes o OnDeinit é executado primeiro (como deveria ser de acordo com a lógica de um leigo) e outras vezes o OnInit é executado primeiro.
Percebo que a resposta está na linha"Durante algum tempo (muito pouco tempo) ambas as cópias do indicador existem em paralelo". Mas isto não torna a questão mais clara.
A função OnInit deve ser executada primeiro no programa.
Você pode dar um exemplo quando a seqüência OnInit -> OnDeinit nem sempre é executada?
A função OnInit deve ser executada em primeiro lugar no programa.
Você pode dar um exemplo quando o OnInit -> OnDeinit nem sempre é executado?
Você pode usar um exemplo do autor do temaERROR.mq5, que ele dá no início. Troque o TF e veja o que acontece na guia Especialistas.
Você pode usar o exemploERROR.mq5 que ele dá no início
Vou experimentá-lo no decorrer do dia. Você já o usou pessoalmente?
É claro que o usei há 9 meses. Você pode ler meu comentário em #8 neste tópico.
Er, não, não é tão simples assim. Os indicadores se situam dentro de outra entidade, o gráfico/ gráfico, e estão subordinados a ele (estou ciente de sua complexa relação de um para muitos, mas isso não muda o ponto). Um gráfico tem seu próprio ciclo de vida, que inclui algum tipo de init e eventos deinit internos, que são os limites para o ciclo de vida dos indicadores. Em outras palavras, um indicador não pode viver mais do que sua tabela. O deinit do gráfico deve esperar pelo deinit ou timeout do deinit de todos os indicadores. Somente então o init gráfico para o novo cronograma pode ser iniciado, e a partir dele os inits dos indicadores anexos podem ser chamados.
Os gráficos são os mesmos que os indicadores. Os indicadores podem 'sobreviver' a seus gráficos.
Antes de iniciar um indicador/conselheiro, os construtores dos objetos globais são executados. Depois do OnDeinit - os destruidores. Portanto, você pode remover o OnInit e OnDeinit de qualquer indicador.
O único problema é não combinar suas idéias sobre os indicadores com a realidade. Talvez, este comportamento seja crítico para alguns freelancers que não conseguem escrever a solução.
Eu gostaria que os desenvolvedores dessem um passo à frente neste tópico. Mas há dois pontos de vista completamente compreensíveis que colidem aqui com sua própria lógica, como deveria ser. Nenhum deles é mais defeituoso do que o outro. É que alguns acham que é assim e outros acham que é assim.
Imagine como os gráficos seriam lentos se antes de mudar a TF o terminal esperasse pela descarga de todos os indicadores da antiga TF e só depois construíssem e inicializassem o novo.
Em que situações, além do trabalho simples com objetos gráficos (sem o nome de TF no nome), a seqüência DeInit - Init é importante?
Imagine como os gráficos seriam lentos se antes de mudar a TF o terminal esperasse pela descarga de todos os indicadores da antiga TF e só depois construíssem e inicializassem o novo.
Em que situações, além do trabalho simples com objetos gráficos (sem o nome de TF no nome), a seqüência DeInit - Init é importante?
+
Mais uma vez. Quando você muda o cronograma ou símbolo no gráfico, uma nova cópia do indicador é criada. Uma nova.
Pela mesma razão que as partes calculadas dos indicadores vivem nas caches históricas. Para cada período de tempo tem seu próprio cache de barras. Quando você muda o cronograma, digamos EURUSD,M1 em EURUSD,H1, para o indicador no cache M1 é enviado o evento Deinit com causa 3 (mudança de gráfico) e depois de um tempo este indicador será descarregado. Se de repente este indicador não teve tempo de lidar com Deinit com a razão 3, ele será deinicializado com a razão 1 (gráfico fechado). Se o cache H1 não existisse naquele momento, então ele será criado. Depois disso, a NOVA cópia indicadora é carregada para o cache H1, para o qual o evento Init é enviado. A nova cópia do indicador não sabe nada sobre a cópia anterior, que está prestes a morrer. Todas as variáveis da nova cópia do indicador estão limpas, elas acabaram de nascer.
Se houver uma mudança de cronograma dentro de um único símbolo, a ordem de inicialização/deinicialização é, em princípio, previsível. Baixe o último build 1580 - corrigimos algumas coisas lá, agora a eliminação dos indicadores é feita na última volta, portanto não deve haver nenhuma desiniteração prematura. Mas, se você muda um símbolo, você fica com uma raça inter-tarefa de forma pura, e não pode prever a seqüência de inicialização-desinicialização sem ambigüidade. Uma vez que caracteres diferentes são processados em fios diferentes
Portanto, uma dica para o iniciante do tópico. Foco na causa da desinicialização. Se for 3, então você não precisa devolver o esquema de cores para o gráfico
Imagine como os gráficos seriam lentos se antes de mudar a TF o terminal esperasse pela descarga de todos os indicadores da antiga TF e só depois construíssem e inicializassem o novo.
Em que situações, além do trabalho simples com objetos gráficos (sem o nome de TF no nome), a seqüência DeInit - Init é importante?
Por que eles seriam lentos? A menos que o indicador esteja escrito de forma incorreta. Para um indicador bem redigido, o DeInit leva muito pouco tempo. Além disso, a comutação TF não é uma operação tão freqüente. Em alguns casos especialmente graves (para indicadores "errados") você pode esperar um ou dois segundos ao trocar de TFs.
Portanto, o argumento sobre a frenagem durante a comutação TF é mais do que duvidoso. Além disso, quando mudamos para a TF que ainda não foi construída, também encontramos um atraso de tempo bastante tangível. E ninguém está chorando por causa dos freios do terminal.