Seqüência de execução Init() e DeInit() - página 10
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
Escrevi claramente - mantenha os dados necessários para transferir para a cópia sempre atualizados, você não precisa fazer isso somente ao entrar, mantenha-os sempre atualizados.
Andrey, você está brincando ou realmente não entende que todos os seus dados reais armazenados em variáveis e matrizes nos indicadores se tornam irrelevantes após a mudança da TF porque a cópia do indicador com todos os seus detalhes é apagada. Na Expert Advisors, é claro, tudo é simples, porque não há reinicialização.
Você deve estar brincando ou não entende que todos os seus dados reais armazenados em variáveis e matrizes nos indicadores se tornam irrelevantes após a mudança da TF, porque a cópia do indicador com todos os seus detalhes é apagada. Em Especialistas, é claro, tudo é simples, porque não há reinicialização.
Não, não estou.
Você não entende o que estou dizendo.
Por exemplo, há um determinado conjunto de dados que precisa ser transferido para outra cópia do indicador (não importa se é outro indicador lançado em um gráfico ou uma nova cópia do indicador quando o TF muda, não importa). O indicador calcula algo e toda vez que ele calcula algo e este algo será aplicado a outros indicadores, este indicador deve ser atualizado. Cada vez. Este banco de dados pode ser armazenado em diferentes locais, dependendo da quantidade de dados e da taxa de transferência de dados necessária. Estes dados precisam ser atualizados sempre que necessário após uma mudança nos dados, e não apenas quando são deinicializados. Esse é o truque. Não há nada de complicado nisso. Não se trata de armazenar os dados nas variáveis locais do indicador, trata-se de reinicializar/atualizar os dados cada vez que os dados foram recalculados.
Mas com os objetos gráficos é muito simples.
Na Expert Advisors, é claro, tudo é simples, porque não há reinicialização.
Não, não estou.
Você não entende o que estou dizendo.
Por exemplo, há um determinado conjunto de dados que precisa ser transferido para outra cópia do indicador (não importa se é outro indicador lançado em um gráfico ou uma nova cópia do indicador quando o TF muda, não importa). O indicador calcula algo e toda vez que ele calcula algo e este algo será aplicado a outros indicadores, este indicador deve ser atualizado. Cada vez. Este banco de dados pode ser armazenado em diferentes locais, dependendo da quantidade de dados e da taxa de transferência de dados necessária. Estes dados precisam ser atualizados sempre que necessário após uma mudança nos dados, e não apenas quando são deinicializados. Esse é o truque. Não há nada de complicado nisso. Não se trata de armazenar dados em variáveis indicadoras locais, trata-se de reinicializar/atualizar os dados cada vez que os dados foram recalculados.
E com objetos gráficos, é bastante simples. Não há necessidade nem de explicar.
É muito discutível que nada seja complicado. Tente realmente replicar no exemplo de uma simples máquina onduladora o que eu implementei neste produto. Na roda de pulso você muda o período com o mouse e depois, quando você muda o TF, as mudanças devem ser salvas, e você pode usar vários indicadores na janela. E você verá que não há nada de complicado. E se você precisar passar um array. E você vai ver como é "simples". Talvez, eu mesmo pensaria assim, se ainda não o tivesse implementado.
É muito discutível que nada seja difícil. Tente realmente replicar no exemplo de um simples demolidor o que eu implementei neste produto. Na roda de pulso você muda o período com o mouse, e então, quando você muda TF, as mudanças devem ser salvas, e é possível usar vários indicadores na janela. E você verá que não há nada de complicado. E se você precisar passar um array. E você vai ver como é "simples".
Só recentemente descobri que todas as variáveis são salvas em EAs ao reinicializar, ou seja, escrevi EAs da mesma forma que os indicadores, assumindo que o programa não sabe nada sobre os outros programas, pois só há seu init e deinit, o programa não deve saber sobre o init e deinit dos outros programas.
É por isso que eu nunca confio na consistência temporal do ininit e do deinit do programa para ser descarregado e executado novamente, eu costumava nunca confiar no fato de que ele pode mudar em algum momento (em 1580 ele mudou). Confiar em bugs indocumentados e futuros de plataformas pode ter um tiro pela culatra no futuro.
Em minha prática, há também produtos que mudam dinamicamente a visualização dependendo das ações do usuário, aplicando tudo - desde eventos até arquivos de troca. Há muito mais indicadores no gráfico do que 1 como regra, os buffers indicadores em 5 são ilimitados e você pode criá-los como parâmetro durante a inicialização. Isto é, somos pessoas criativas, precisamos ter uma abordagem flexível para resolver nossas tarefas e ao mesmo tempo ter em mente as especificidades de 3 tipos de programas, mas os desenvolvedores da plataforma estão preocupados com outros problemas, que são mais importantes do que pequenas dificuldades em comparação com as tarefas globais da plataforma.
Existem defeitos realmente importantes na plataforma, sobre os quais eles não falam muito ou não falam nada, é muito mais importante do que o problema dos "inits e deinserts".
Se o cronograma for mudado para baixo, OnInit no menor (novo) cronograma primeiro e depois OnDeinit no maior (antigo) cronograma.
Se o interruptor sobe, então é o contrário. Primeiro OnDeinit no período inferior (antigo) e depois OnInit no período superior (novo).
Aqui devemos ter em mente que as caches são processadas desde o menor até o maior prazo
Isto é simplesmente horrível. Os programadores de aplicação não devem pensar em tais coisas sistêmicas. A plataforma pode lidar com as caches internamente como quiser, mas no nível do MQL deve trazer tudo transparentemente em um único contrato de evento, sem possíveis efeitos colaterais. Todas as referências a supostas considerações de eficiência e a possibilidade de todos trabalharem sozinhos em torno do problema são simplesmente insustentáveis. É possível fazer de uma vez por todas, de forma eficaz e conveniente (eliminando a possibilidade de pisar neste ancinho).
Isso mesmo, eles não deveriam. Assim, você dirige o Comandante Total, por exemplo. Por que exigir da Microsoft que o Windows cuide da seqüência "correta" de upload/download de cópias TC para a RAM? Isso é uma preocupação do sistema operacional?
A preocupação do OS é que o TC não interfira com outros TCs e com o que eles fazem lá na RAM, trocar arquivos ou qualquer outra coisa que seja seu negócio.
"Eu acho que sim!" (c) Mimino, 1977.
Eu gostaria de resumir e resumir o acima exposto. Então, antes do lançamento da construção 1580 do MT5 (construção atual 1571), o que nós temos?
Nos indicadores, ao contrário dos Expert Advisors, quando a TF muda, porque"uma nova cópia do indicador é criada, que não sabe nada sobre a cópia anterior", todas as variáveis são reinicializadas, além da ordem de execução do OnDeinit da antiga TF e OnInit da nova TF é imprevisível, independentemente de a TF ser "para cima" ou "para baixo" (prática, ao contrário do que foi mencionado pelo Sr. Slava). Neste contexto, os programadores têm uma série de problemas e incertezas. Por exemplo:
- o programador, que não leu este tópico, cria um objeto para algo no OnInit, verificando logicamente antes da criação do indicador para a existência de um objeto com este nome. Também é lógico prescrever a remoção deste objeto no OnDeinit. Quando o TF é modificado, se primeiro o OnInit do novo TF é executado, ele verifica a existência do objeto, acontece que ele já existe, e ele não é criado, porque já foi criado. Depois disso, o OnDeinit do antigo TF é realizado e o objeto é removido. O programador está em estado de choque. Onde está meu objeto e por que ele desapareceu? Ele ficará ainda mais confuso, quando da próxima vez que a TF for alterada, quando a seqüência de OnInit e OnDeinit for diferente, o objeto não será removido. É excluído, não é excluído.... Depois de uma longa pesquisa começará a se dirigir ao Service Desk, novos tópicos no fórum sobre o antigo.
Esta é apenas a situação mais simples. Haverá outras, pois esta característica não está descrita na documentação e você só poderá ler sobre ela no fórum.
Se você quiser criar algo especial e passar alguns parâmetros da cópia antiga do indicador para a nova, ao mudar o TF, não poderá usar o OnDeinit, devido à seqüência imprevisível das operações de inicialização e deinicialização. Na minhaopinião, a melhor solução neste caso é usar as seguintes ferramentas:ResourceCreate baseado na matriz de pixels eResourceReadImage, mas é bastante complicado e você precisa cuidar do conflito de recursos, se você usar vários indicadores idênticos em uma janela, e toda vez que os dados que você deseja enviar para outra cópia precisam ser salvos em um recurso não reinicializado, porque o tempo de possível mudança de TF não é conhecido para a aplicação. Eu implementei isto há muito tempo (por exemplo, neste produto), então eu sei do que estou falando. A implementação da transferência de dados através de arquivos e variáveis globais de terminal é uma solução menos bem-sucedida (IMHO).
Se a nova construção 1580 serácomo diz Slava, não facilitará a tarefa, pois a desinicialização da cópia antiga do indicador será realizada após a inicialização de uma nova. Mas não haverá incerteza.
Temos que esperar que os desenvolvedores tenham prestado atenção a este problema, uma vez que estão tentando resolvê-lo.
Estamos esperando por uma nova construção.
Concordo plenamente que este recurso de processamento DEVE ser mencionado na documentação, caso contrário os recém-chegados enfrentarão este problema e virão aos fóruns em busca de uma solução. (Por que, quando você pode lhes falar sobre isso imediatamente nos documentos Terminal e MQL).
Acrescente também à documentação que o registro não mostra um quadro completo dos eventos, mas apenas uma parte dele. Veja os registros completos para uma imagem completa.
Sobre o resto depois ...
Eu gostaria de resumir e resumir o acima exposto. Então, antes do lançamento da construção 1580 do MT5 (construção atual 1571), o que nós temos?
Nos indicadores, ao contrário dos Expert Advisors, quando a TF muda, porque"uma nova cópia do indicador é criada, que não sabe nada sobre a cópia anterior", todas as variáveis são reinicializadas, além da ordem de execução do OnDeinit da antiga TF e OnInit da nova TF é imprevisível, independentemente de a TF ser "para cima" ou "para baixo" (prática, ao contrário do que foi mencionado pelo Sr. Slava). Neste contexto, os programadores têm uma série de problemas e incertezas. Por exemplo:
- o programador, que não leu este tópico ao criar um indicador para algo no OnInit, cria um objeto, verificando logicamente antes da criação do objeto com este nome. Também é lógico prescrever a remoção deste objeto no OnDeinit. Quando o TF é modificado, se primeiro o OnInit do novo TF é executado, ele verifica a existência do objeto, acontece que ele já existe, e ele não é criado, porque já foi criado. Depois disso, o OnDeinit do antigo TF é realizado e o objeto é removido. O programador está em estado de choque. Onde está meu objeto e por que ele desapareceu? Ele ficará ainda mais confuso, quando da próxima vez que a TF for alterada, quando a seqüência de OnInit e OnDeinit for diferente, o objeto não será removido. É excluído, não é excluído.... Após uma longa pesquisa começará a se dirigir ao Service Desk, novos tópicos no fórum sobre o antigo.
Esta é apenas a situação mais simples. Haverá outras, pois esta característica não está descrita na documentação e você só poderá ler sobre ela no fórum.
Se você quiser criar algo especial e passar alguns parâmetros da cópia antiga do indicador para a nova, ao mudar o TF, não poderá usar o OnDeinit, devido à seqüência imprevisível das operações de inicialização e deinicialização. Na minhaopinião, a melhor solução neste caso é usar as seguintes ferramentas:ResourceCreate baseado na matriz de pixels eResourceReadImage, mas é bastante complicado e você precisa cuidar do conflito de recursos, se você usar vários indicadores idênticos em uma janela, e toda vez que os dados que você deseja enviar para outra cópia precisam ser salvos em um recurso não reinicializado, porque o tempo de possível mudança de TF não é conhecido para a aplicação. Eu implementei isto há muito tempo (por exemplo, neste produto), então eu sei do que estou falando. A implementação da transferência de dados através de arquivos e variáveis globais de terminal é uma solução menos bem-sucedida (IMHO).
Se a nova construção 1580 serácomo diz Slava, não facilitará a tarefa, pois a desinicialização da cópia antiga do indicador será realizada após a inicialização de uma nova. Mas ao menos não haverá incerteza.
Espero que os desenvolvedores tenham prestado atenção a este problema desde que tentaram resolvê-lo.
Estamos esperando por uma nova construção.
O Expert Advisor funciona bem ao trocar o TF, e o indicador nesta situação funciona de forma muito diferente.
Não há problema se você estiver ciente deste recurso indocumentado e lidar apenas com o caso mais simples - o gráfico. objetos. Quero dizer, aqueles que não conhecem esta característica, acho que este tópico neste fórum será lido por uma porcentagem muito pequena de programadores e tenho pena de seu tempo para descobrir todas as nuances. Eu já tinha estado nesta situação antes de entender a essência.