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

 
Ihor Herasko:


Por que eles seriam lentos? A menos que o indicador esteja mal escrito. Um indicador DeInit bem redigido 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 você muda para o TF que ainda não foi construído, o atraso de tempo é bastante palpável. E ninguém chora sobre os freios do terminal.

Os indicadores são diferentes. Há também os mais lentos. E nem todos eles são próprios e em código fonte.

Eu me divirto por um par de segundos. Sinto dezenas de milissegundos na interface, sinto desconforto de uma só vez.

E, o mais importante, não há resposta para minha pergunta:
Em que situações, exceto no trabalho direto com objetos gráficos (sem o nome TF no título), a seqüência DeInit - Init é importante?

 
Andrey Khatimlianskii:

Os indicadores vêm em todas as formas e tamanhos. Os travados também. E nem todos eles são próprios e em código fonte.

Um par de segundos é engraçado. Você pode sentir dezenas de milissegundos na interface, há desconforto de uma só vez.

E, o mais importante, não há resposta à minha pergunta:
Em que situações, além do trabalho direto com objetos gráficos (sem o nome TF no nome), a seqüência DeInit - Init é importante?


Normalmente não uso variáveis globais, mas às vezes isso acontece.

Quando trabalhamos com variáveis globais, ficamos confusos. Ao apagar o indicador do gráfico, você precisa limpar depois de si mesmo e apagar as variáveis globais. Em que lugar do indicador você apaga as variáveis globais? Provavelmente, deve ser apagado em Deinite, não há outro lugar. Assim, quando você muda o prazo e cria novas variáveis, Deinite vem e apaga tudo. Acontece que as Variáveis Globais não podem ser usadas em indicadores.

 
Sergey Chalyshev:


Normalmente não uso variáveis globais, mas às vezes isso acontece.

Ao trabalhar com variáveis globais, você fica agitado. Ao remover o indicador do gráfico, você precisa limpar depois de si mesmo e remover as variáveis globais. Em que lugar do indicador você irá apagar as variáveis globais? Provavelmente, deve ser apagado em Deinite, não há outro lugar. Assim, quando você muda o prazo e cria novas variáveis, Deinite vem e apaga tudo. Acontece que as Variáveis Globais não podem ser usadas em indicadores.

Sergiy, você tem um exemplo real que não seja tirado do nada? Também posso pensar em tal exemplo, mas não tenho enfrentado nenhum problema na prática.

Nota: Variáveis globais também podem ser nomeadas, dependendo da TF.

 
Andrey Khatimlianskii:

Os indicadores vêm em todas as formas e tamanhos. Os travados também. E nem todos eles são próprios e em código fonte.

Um par de segundos é engraçado. A interface parece dezenas de milissegundos, o desconforto aparece imediatamente.

E, o mais importante, não há resposta à minha pergunta:
Em que situações, além do trabalho direto com objetos gráficos (sem um nome TF no título), a seqüência DeInit - Init é importante?

Na página 3 eu dei um exemplo prático:
A primeira coisa que me vem à mente é que no meu deinit o estado anterior (botões pressionados/ soltos) é armazenado nas variáveis globais e depois os botões são definidos de acordo com os valores salvos nos inits. E são os botões que nem sempre são reajustados corretamente. Esta é a primeira coisa que me lembro, talvez encontre outra coisa...
 
elibrarius:
na página 3 dei um exemplo prático:

memorizar na cabeça do terminal cada vez que as variáveis relevantes são alteradas, não quando ini/deinit.
 
Andrey Dik:

lembrar no terminal principal cada vez que as variáveis correspondentes são alteradas, não quando ini/deinit.

Vou me lembrar)
E lembre-se também, que na implementação atual nada pode ser feito em Deinit que então deve ser usado (nem em variáveis globais nem na escrita de arquivos)...

essencialmente inúteis os finci se tornaram, com uma seqüência tão quebrada.

Vou me lembrar (ainda bem que tropecei neste fio por acidente), mas outros programadores (que não olharão aqui) usarão a conseqüência lógica natural e usarão Deinit esperando que funcione, e então o init funcionará em um novo TF.

 
elibrarius:

Vou me lembrar)
Lembre-se também que a implementação atual do terminal não permite fazer nada no Deinit que deva ser usado posteriormente (nem em variáveis globais, nem em arquivos)...

essencialmente um finkzi inútil, com uma seqüência tão quebrada

Basta entender que também existe outra lógica. A lógica dos desenvolvedores da MT, em particular. De acordo com isto, outra lógica tudo parece bastante lógico. Daí a conclusão: ajuste-se a esta lógica e não tente mudar a mente das pessoas que provavelmente são mais experientes do que você nisto. É inútil... Ninguém concordará em mudar a lógica estabelecida por causa de um indicador.
 
Bem, eu não sou o primeiro a ter este problema, então não é por um indicador. Já fiz tudo isso por mim, mas outros também podem estar pisando neste ancinho. Não seria melhor simplesmente remover o ancinho para que ninguém mais o pise?
 
Alexey Viktorov:
Basta entender que também existe outra lógica. A lógica dos desenvolvedores da MT, em particular. De acordo com esta, outra lógica, tudo parece bastante lógico. Daí a conclusão: ajuste-se a esta lógica e não tente mudar a mente das pessoas que provavelmente são mais experientes do que você nisto. É inútil... Ninguém concordará em mudar a lógica estabelecida por causa de um indicador.


Se não se tratasse de finanças, talvez não tivesse havido tal discussão.

E como um assessor comercial depende de um indicador ou de outro, ele simplesmente deixará de funcionar corretamente por causa de uma simples troca da TF. Isso é o que é mais estressante.

Então, como você pode confiar-lhe suas finanças?

Podemos estar em desacordo com os desenvolvedores da MT neste caso.
 
Andrey Khatimlianskii:

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ó então 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?

Vocês estão todos confundindo um monte de coisas diferentes. Vamos concordar em pelo menos dois requisitos para o terminal como software crítico:

- deve funcionar de forma previsível, seguindo rigorosamente a mesma lógica (mesmo com multi-tarefas);

- deve funcionar rapidamente.

(não é importante se a cópia do indicador conhece outras cópias, mas é importante que os dados globais, designados para armazenamento no terminal, sejam consistentes - esta é a preocupação do terminal, não de cada desenvolvedor de indicador)

Além disso, há uma questão - como implementá-la. Agora ela é implementada levando em conta o requisito 2. Proponho implementá-la considerando o requisito 1, sem afetar o requisito 2.

Não haverá abrandamentos notáveis, se prestarmos atenção ao fato de que os eventos de init/deinit chart e init/deinit of indicator são coisas diferentes. O gráfico mostrará imediatamente o novo gráfico principal, mas para os indicadores legados, o evento OnInit será enfileirado após o processamento do OnDeinit anterior. De qualquer forma, os eventos estão enfileirados no terminal.

Se a MQ desejar, pode me enviar em seus termos gráficos de classes e seqüências NDA, eu os corrigirei ;-)