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

 
Nikolai Semko:
Obrigado pelo código, é claro. Mas os EAs estão bem em qualquer caso porquequando eu mudo o TF eles não reinicializam as variáveis, enquanto os indicadores o fazem. Se você realmente quer ajudar com conselhos, por favor, "corra" novamente com menos pressa.

Nicholas, eu me deparei com o tema, mesmo quando escrevi o primeiro post. E não encontrei nenhuma discussão sobre como um EA se comporta quando o cronograma muda. Sim - o tópico é principalmente sobre indicadores, enquanto o autor escreveu em seu post"Um indicador ou um Expert Advisorestá escrito ".

Dei um exemplo que verifiquei e funciona dentro da estrutura do Expert Advisor. Mas você - depois me censura por inconsideração, depois me envia para reler o tópico, depois discute - o que é razoável ou não razoável. Além disso, você pode ler a primeira página

Não está claro se você está falando de um Expert Advisor ou de um indicador. Você nem mesmo diz claramente em seu posto que está falando de um indicador.

VEJA UM EXEMPLO DO SEU POSTO:

Nikolai Semko:
Então, é isso?
Tenho experimentado e utilizado este código de motivo (REASON_CHARTCHANGE) em toda a sua extensão. Mas de que adianta se todas as variáveis forem definidas para seu estado inicial e o OnDeinit for executado após o OnInit do novo TF?

Está claro pelo que acabei de dizer que as variáveis são inicializadas no indicador?

A pessoa que lê seu posto pode pensar que a mesma coisa acontece em um Consultor Especialista.

----

A resposta a esta pergunta!"Quando você muda de TF, a reinicialização variável não ocorre, enquanto ela ocorre em indicadores".

Andrey Dik:
você pode salvar valores variáveis em algum lugar, em globais, por exemplo...

Se você quiser usar o método OnInit, você tem que ler e restaurar os valores da mesma maneira.

------------

Se você estiver interessado apenas no problema de trocar o TF pelo indicador - isso não significa que outros, inclusive eu, não estejam interessados na opção de trocar o TF pelo EA.

Não possodar conselhos sobre o indicador, porque não sei como fazê-lo na prática, mas estarei observando com interesse as soluções sugeridas.

Entendi que os desenvolvedores estão lendo este tópico e até corrigiram algumas coisas na construção 1580. Talvez eles ofereçam soluções.

 
Slawa:

Você não leu o que eu escrevi várias vezes?

Não há como nos indicadores. Não se pode fazer isso nos indicadores desde o início. Porque você tem que baixar uma cópia completamente nova do indicador com todas as suas conseqüências.


Obrigado por sua resposta honesta.

Sempre foi assim em 5. Talvez seja hora de consertá-la?

É realmente tão difícil fazer a ordem correta? A economia de tempo no início se traduz então em verificações intermináveis em cada tick.

Já me acostumei ao paradigma OOP do MT5 e sei onde está o ancinho e como consertar as muletas para contornar esses ancinhos, é claro, se não houver novas. Acontece que é mais fácil apagar um objeto e criar um novo do que alterar um par de parâmetros.

Da mesma forma, em um carro, em vez de trocar o óleo e dirigir, é melhor jogar o carro fora e fazer um novo.

Faz-me lembrar um desenho animado:


Download do vídeo
 

Você pode me dizer, por favor?

Eu decidi escrever um programa que

1. sobre as saídas da Inite 8 linhas

2. em saídas DeInite mais 8 linhas.

Eu o corri no testador (eu o corri por 2 dias e o consegui).

Por alguma razão, ele não registra seletivamente algumas cordas.

Isto também é para acelerar as coisas????


------------------------------------------------------------------------------------------

QUESTÃO ESCLARECIDA PORQUE OS REGISTROS COMPLETOS TÊM TODAS AS INFORMAÇÕES

------------------------------------------------------------------------------------------

Na documentação, é necessário acrescentar

1. O registro não mostra todas as informações que o programador espera

-------- É ESSENCIAL VER O LOG COMPLETO!!!

Arquivos anexados:
Log2.txt  2 kb
ERROR_2.mq5  2 kb
 

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. Em seguida, 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 desinicializaçã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.

Espero que os desenvolvedores tenham prestado atenção a este problema, pois eles estão tentando consertar algo.
Esperamos pela nova construção.

 

Todos os objetos gráficos são nomeados com referência ao TF atual. Na inicialização que criamos, na desinicialização que apagamos. Durante o funcionamento do indicador, modificar conforme necessário.

Há algum problema aqui? Não há problema. Tudo é normal desde o momento do início do indicador até o momento de seu descarregamento.

Nós trocamos a TF. Não importa para que lado vá, para cima ou para baixo. Uma cópia do indicador é lançada. Isto é equivalente ao fato de que o indicador foi lançado pela primeira vez nesta TF.

Há algum problema aqui? Não há nenhum problema. A cópia antiga cuidará de remover seus objetos, e a nova cópia criará novos objetos de acordo com o cronograma atual.

O que eu estou fazendo de errado? Por que eu não vejo um problema?

 
Andrey Dik:

Todos os objetos gráficos são nomeados com referência ao TF atual. Na inicialização que criamos, na desinicialização que apagamos. Durante o funcionamento do indicador, modificar conforme necessário.

Há algum problema aqui? Não há problema. Tudo é normal desde o momento do início do indicador até o momento de seu descarregamento.

Nós trocamos a TF. Não importa para que lado vá, para cima ou para baixo. Uma cópia do indicador é lançada. Isto é equivalente ao fato de que o indicador foi lançado pela primeira vez nesta TF.

Há algum problema aqui? Não há nenhum problema. A cópia antiga cuidará de remover seus objetos, e a nova cópia criará novos objetos de acordo com o cronograma atual.

O que eu estou fazendo de errado? Por que eu não vejo um problema?

Não há problema se você conhece este recurso indocumentado e só lida com o caso mais simples - com gráfico. objetos. Quero dizer, aqueles que não conhecem esta característica, acho que este tópico é lido por uma porcentagem muito pequena de programadores neste fórum e tenho pena de seu tempo para descobrir todas as nuances. Eu já estive nesta situação antes de entender a essência.
 
Nikolai Semko:
Não há problema se você estiver ciente deste recurso indocumentado e lidar apenas com o caso mais simples - com gráfico. objetos. Quero dizer, aqueles que não conhecem esta característica, acho que este tópico é lido por uma porcentagem muito pequena de programadores neste fórum, e tenho pena do tempo deles para descobrir todas as nuances. Eu já tinha estado nesta situação antes de entender a essência.

Nunca ouvi falar de nuances como as descritas neste tópico, mas nunca encontrei problemas com os problemas aqui descritos.

Se você quiser transferir algo para outra cópia do indicador, não precisa fazê-lo deinit - manter os dados transferidos atualizados durante toda a vida útil do indicador - por exemplo, nas principais variáveis do terminal, então não importa o motivo da descarga do indicador (mudança de TF, minha mãe puxou a tomada "para não cantarolar quando todos dormem", terremoto, mudança dos pólos magnéticos da terra e assim por diante.etc.) a próxima execução do indicador (incluindo uma cópia quando a TF mudar) obterá todas as informações necessárias desta fonte de dados mágica (para os casos azarados de escala global você pode manter os dados em uma unidade de nuvem).

Rapazes, não há problema algum.

 
Andrey Dik:

Todos os objetos gráficos são nomeados com referência ao TF atual. Na inicialização que criamos, na desinicialização que apagamos. Durante o funcionamento do indicador, modificar conforme necessário.

Há algum problema aqui? Não há problema. Tudo é normal desde o momento do início do indicador até o momento de seu descarregamento.

Nós trocamos a TF. Não importa para que lado vá, para cima ou para baixo. Uma cópia do indicador é lançada. Isto é equivalente ao fato de que o indicador foi lançado pela primeira vez nesta TF.

Há algum problema aqui? Não há nenhum problema.

Há um problema: a existência simultânea de objetos de diferentes indicadores. "Desculpe, temos problemas técnicos temporários" (mas isso será resolvido em alguns segundos quando o velho indicador DeInit acontecer)

A cópia antiga se encarregará de remover seus objetos, e a nova cópia criará seus novos objetos, nomeando-os de acordo com a TF atual.

O que eu estou fazendo de errado? Por que eu não vejo nenhum problema?

É uma visão estreita. É por isso que você não consegue ver. Amplie um pouco seus horizontes. Os primeiros problemas ocorrem durante o trabalho com os arquivos, pois não está claro se o indicador anterior teve tempo para salvar os dados no arquivo ou ainda não. Algumas bandeiras nas variáveis globais do terminal terão que ser criadas. A nova cópia do indicador terá que esperar que a cópia antiga reinicialize os dados acumulados. A propósito, o problema é que tal sincronização só é possível na OnCalculate(). E o que fazer se a troca acontecesse no fim de semana? Uma nova cópia não começará até segunda-feira? Ah, sim, podemos colocá-lo em um temporizador! Ouvi dizer que se pode atirar em pardais com um canhão, a fisga seria uma boa maneira de ir.

Estes ainda são problemas simples. Tente levar esta lógica em consideração ao trabalhar com DLL multi-tarefa. Agora é aqui que a diversão começa. Bem, nós vamos ficar mais fortes ))))

 
Andrey Dik:

Nunca ouvi falar de nuances como as descritas neste tópico, mas nunca encontrei nenhum problema com os problemas aqui descritos.

Se você quiser transferir algo para outra cópia do indicador, não precisa fazê-lo deinit - manter os dados transferidos atualizados durante toda a vida útil do indicador - por exemplo, nas principais variáveis do terminal, então não importa o motivo da descarga do indicador (mudança de TF, mamãe puxou o plugue "para não cantarolar quando todos dormem", terremoto, mudança de pólos magnéticos da terra e assim por diante.etc.) o próximo lançamento do indicador (incluindo cópia na TF change) obterá todas as informações necessárias desta fonte de dados mágica (para casos azarados de escala global é possível manter os dados em disco na nuvem).

Rapazes, não há problema algum.

Responderei amanhã. OK? Dirigir é fácil.
 
Ihor Herasko:

Há um problema: a existência simultânea de objetos de diferentes indicadores. "Desculpe, temos problemas técnicos temporários" (mas eles serão corrigidos em alguns segundos, quando o velho indicador DeInit ocorrerá)

Um campo de visão estreito. É por isso que você não pode ver. Amplie um pouco seus horizontes. Os primeiros problemas já ocorrem quando se trabalha com arquivos, pois não está claro se o indicador anterior conseguiu ou não salvar os dados no arquivo. Algumas bandeiras nas variáveis globais do terminal terão que ser criadas. A nova cópia do indicador terá que esperar que a cópia antiga reinicialize os dados acumulados. A propósito, o problema é que tal sincronização só é possível na OnCalculate(). E o que fazer se a troca acontecesse no fim de semana? Uma nova cópia não começará até segunda-feira? Ah, sim, podemos colocá-lo em um temporizador! Ouvi dizer que se pode atirar em pardais com um canhão, a fisga seria uma boa maneira de ir.

Estes ainda são problemas simples. Tente levar esta lógica em consideração ao trabalhar com DLL multi-tarefa. Agora é aqui que a diversão começa. Bem, nós vamos ficar mais fortes))))

Eu já escrevi claramente - mantenha os dados necessários para copiar sempre atualizados. Você não precisa fazer isso somente durante a entrada, você deve sempre mantê-los atualizados.

Todos os outros casos são contornados devido à manivela.

Se houver um problema com a execução do mesmo indicador ao mesmo tempo, então crie objetos únicos cada vez com um link para o TF e se já houver objetos, adicione 1 ao nome.

Ninguém citou um único caso em que os problemas são intransponíveis devido à maneira atual como o terminal funciona com indicadores. Os problemas são causados por um trabalho incorreto com indicadores.

Em geral, muitas pessoas parecem não entender que existem 3 tipos de programas por uma razão (o 4º estará disponível em breve).