Seqüência de execução Init() e DeInit() - página 2

 
Alexey Viktorov:

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?
 
Slawa:

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.
 
Nikolai Semko:
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
Eu só li sobre a eliminação de um objeto na desinicialização e estava apenas respondendo a este problema. É mais complicado com a economia de cálculos passados. E aparentemente este problema nunca será resolvido. Slava respondeu a esta pergunta, novo indicador, novos cálculos. E isto é justo.
 
Alexey Viktorov:
Slava respondeu a esta pergunta, novo indicador, novos cálculos. E isto é justo.
A questão é que o indicador é o mesmo, mas o cronograma é novo. E a questão é sobre a dessincronização da unidade e da unidade, ou seja, a seqüência inversa (ilógica) de execução ocorre, e às vezes é lógica. Não há nada pior para um programador do que um erro e uma lógica flutuante.
 
Alexey Viktorov:
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.
 
Nikolai Semko:

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

 
nmaratr:

- 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:

 // --- Переменная для хранения текущего ТФ
ENUM_TIMEFRAMES currentTF;

//+---------------------------------------------------------------------------+
void OnInit()
{
  currentTF = (ENUM_TIMEFRAMES)Period();
}

//+---------------------------------------------------------------------------+
void OnDeinit(const int reason)
{
   // --- на момент выгрузки индикатора уже сменился ТФ
  if(currentTF != Period()) 
  {
    // если нужно, удалим объекты имеющие префикс старого ТФ и выходим, не трогаем цвет основного графика
    return;
  }

  // раз дошли сюда, ТФ не сменился, восстанавливаем цвет основного графика
  // удалим объекты имеющие префикс старого ТФ
}
 
nmaratr:

- 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".

É claro que é melhor quando tudo acontece em uma seqüência lógica, mas como temos que trabalhar com o que temos, podemos mover a cor do gráfico principal para OnCalculate com verificação do valor atual.
 
Nikolai Semko:
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

Новая версия платформы MetaTrader 4 build 1065
Новая версия платформы MetaTrader 4 build 1065
  • www.mql5.com
Новая версия платформы MetaTrader 4 build 106523 марта 2017 года будет опубликовано обновление платформы MetaTrader 4...
 
Aleksei Radchenko:


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

Estamos falando do MT5
Razão: