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
Esta questão é resolvida como dois dedos... você sabe o que...
No OnDeinit é necessário condicionar o motivo da desinicialização antes de apagar o objeto... Se não for uma mudança de período, então o objeto é apagado. E É SÓ ISSO...
Sim, eu não posso apagar algum objeto ou recurso na TF change, posso até salvar algumas pequenas matrizes através de recursos de objetos, e escrever em informações de recursos sobre a TF change, mas a questão éMinha unidade pode começar a ser executada após a unidade ter sido executada em um novo prazo. Como devo informar à unidade que o prazo mudou e os dados antigos devem ser lidos? Não é errado?
Que tipo de lógica é estragada?
Quando você muda o cronograma, uma nova cópia do indicador é criada e não sabe nada sobre a cópia anterior. Durante um certo período de tempo (muito curto), ambas as cópias do indicador existem em paralelo. Depois, a cópia anterior é descarregada.
Leia a documentação https://www.mql5.com/ru/docs/runtime/running
Eu li a descrição do link, mas não encontrei tal informação, como você deu. E se for realmente assim, é um grande problema para os desenvolvedores de indicadores. É muito estranho e muito ruim que tal lógica seja adotada para os indicadores de recarga quando se muda o cronograma. Por que precisamos da existência de duas cópias do mesmo indicador na memória? Quem se beneficia com isso? O que ele dá? Seria mais lógico completar a execução de uma cópia do indicador, descarregá-lo e só depois carregar a cópia seguinte.
E isso é TUDO!?
Tenho experimentado e utilizado este código de motivo(REASON_CHARTCHANGE) o máximo possível. E qual é a utilidade se todas as variáveis forem novamente definidas para seu estado original, e OnDeinit pode ser executado após OnInit de uma nova TF
Slava respondeu a esta pergunta, novo indicador, novos cálculos. E isto é justo.
E aparentemente este problema nunca será resolvido.
E eu tenho fé na equipe de desenvolvimento, eles são grandes caras e fizeram uma quantidade incrível e vão fazer mais. Só ainda não cheguei a esse ponto. É verdade, você sempre tem que obter feedback deles com sinos e apitos. :))
Minha tarefa é convencê-los de que isso precisa ser feito. Embora eu não exclua que eles me convençam de que é melhor não fazer, talvez eu não entenda alguma coisa.
E eu tenho fé na equipe de desenvolvimento, eles são grandes caras e fizeram uma quantidade incrível e vão fazer mais. Só ainda não cheguei a esse ponto. Mas é sempre difícil obter feedback deles. :))
Minha tarefa é convencê-los de que isso precisa ser feito. Embora eu não exclua que eles me convençam de que é melhor não fazer, talvez eu não entenda alguma coisa.
Slawa, o que significa a frase na documentação"As bibliotecasnão lidam com nenhum evento"?
Muito vago
- Quando Inite define a cor do gráfico principal como transparente.
Eu desenho minha própria carta (de acordo com meus parâmetros)
Quero que ele restaure a cor do gráfico principal após a remoção do meu indicador
- No DeInit eu restauro a cor da carta principal
Ao mudar o TF quero dizer primeiro DeInit (restaurar a cor), e depois Init (voltar a ser transparente)
A execução dos comandos não é seqüencial; periodicamente, ao alterar o TF
periodicamente a tabela principal (com a cor restaurada) é sobreposta ao meu indicador.
Aqui está, por exemplo, uma "quebra lógica".
Talvez para tentar atribuir aos objetos gráficos o período TF como um componente do prefixo de seu nome,
e depois aplicar algo como isto:
- Quando Inite define a cor do gráfico principal como transparente.
Eu desenho minha própria carta (de acordo com meus parâmetros)
Quero que ele restaure a cor do gráfico principal após a remoção do meu indicador
- No DeInit eu restauro a cor da carta principal
Ao mudar o TF quero dizer primeiro DeInit (restaurar a cor), e depois Init (voltar a ser transparente)
A execução dos comandos não é seqüencial; periodicamente, ao alterar o TF
periodicamente a tabela principal (com a cor restaurada) é sobreposta ao meu indicador.
Aqui está, por exemplo, uma "quebra lógica".
E isso é TUDO!?
Tenho experimentado e utilizado este código de motivo(REASON_CHARTCHANGE) o máximo possível. E qual é a utilidade se todas as variáveis forem novamente definidas para o estado original, e OnDeinit pode ser executado após OnInit do novo TF
Tente atualizar o terminal para a versão 1065. Nas versões anteriores, houve um erro de reinicialização apenas durante a mudança do cronograma. Pode ajudar :)
https://www.mql5.com/ru/forum/187690
Tente atualizar o terminal para a versão 1065. As versões anteriores tiveram um erro de reinicialização apenas pela mudança do cronograma. Pode ajudar :)
https://www.mql5.com/ru/forum/187690