Seqüência de execução Init() e DeInit() - página 7
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
Se houver uma mudança de cronograma dentro de um símbolo, então a ordem de inicialização e deinicialização é, em princípio, previsível. Faça o download do último build 1580 - corrigimos algumas coisas lá, agora os indicadores são removidos por último, portanto não deve haver desiniteração prematura.
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.
Não se torça. Não se trata da interface, mas sim dos transientes - comutação TF. Em uma tabela em branco, a comutação TF leva um tempo infinitesimal? Não. Então os indicadores não têm nada a ver com isso.
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 nome), a seqüência DeInit - Init é importante?
Em quase todas as situações. A menos, é claro, que lidemos com brinquedos do tipo MAshek e primitivos similares:
De acordo. Outros problemas que não o segundo são resolvidos, se você souber deles. Ou seja, agora devemos enfiar toda a lógica na OnCalculate, enquanto o Init e o DeInit não devem ser usados. Mas para que precisamos deles então?
De qualquer forma, não estamos falando agora de cross-platformity. Acontece que o MT4 e o MT5 têm abordagens diferentes do Init e do DeInit.
Se não se tratasse de finanças, talvez não houvesse 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 suas finanças?
Podemos estar em desacordo com os desenvolvedores da MT sobre este assunto.Há muitas opções para resolver este problema. E quase todas elas foram expressas nesta linha.
1. Se o indicador for escrito pelo Consultor Especialista, este deve ser escrito de tal forma que não seja afetado por mudanças de período do gráfico. Portanto, o indicador não será reinicializado.
2. Se você tiver que apagar objetos gráficos ou alterar o desenho do gráfico em deinit, então verifique o motivo para a deinicialização.
Se o indicador precisar salvar alguns parâmetros, então, como já foi dito aqui, não salve estes dados no deinit, mas quando estes dados forem preparados ou alterados.
4) De duas pilhas de porcaria, escolha sempre aquela que fede menos. Assim, ao escolher entre a velocidade da qual TODOS os indicadores dependem e a complexidade de salvar alguns dados nos indicadores SEVERAL, eu escolho a velocidade.
Eu não entendo. Por favor, esclareça. O deinit será garantido após o init?
Se a chave de tempo cair, então primeiro OnInit no menor (novo) tempo, e depois OnDeinit no maior (antigo) tempo.
Se o interruptor está subindo, então é o inverso. 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
Faça o download do último build 1580 - nós consertamos algumas coisas lá, agora os indicadores são removidos por último, portanto não deve haver nenhuma desiniteração prematura.
(( Oh cara, isso é "boas notícias". Agora talvez eu tenha que reescrever o código em alguns programas, porque ele foi projetado para "o contrário" - primeiro Deunit, depois Unit.
Para ser honesto, é uma lógica estranha. Isso significa que as cópias do antigo e do novo indicador viverão juntas sem ambigüidade por algum tempo, até que a unidade seja executada na nova cópia do indicador primeiro e Deunit na antiga depois dela. Naquele momento não há possibilidade de informar a nova cópia sobre algumas informações através da Deunit. Isto é obviamente uma bagunça. Para as unidades são normalmente muito mais incômodos do que as unidades. Por que uma seqüência tão estranha de execução! Então, este tópico será reavivado repetidamente. Mas se o programador no indicador poderia criar algumas variáveis que não são reinicializadas ao mudar o TF, então vamos lidar com esta seqüência de OnInit e OnDeinit. Eu já escrevi sobre isso algumas vezes(1 e 2). Concordo com a lógica dos desenvolvedores, que por razões de segurança as indicações e referências não são um luxo para programadores, mas se você criar um mecanismo de um tipo especial de variáveis compartilhadas para todas as cópias do indicador, teremos que criar o mesmo mecanismo para todas as cópias do indicador. O indicador é o mesmo, as propriedades do indicador são armazenadas "em algum lugar".
Se a mudança de cronograma cair, primeiro OnInit no menor (novo) cronograma e depois OnDeinit no maior (antigo) cronograma.
Se o interruptor está subindo, 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 de baixo para alto
Isto é ainda mais confuso.
Afinal, se o indicador não for usado pelo próprio autor, então ele pode trocar como quiser sem esperar pelo init e deinit? E o que vai acontecer? E se para uma variante de interruptor em deinit é necessário fazer algumas ações, então não faz nenhuma diferença se está escrito para uma direção de interruptor ou para ambas as direções. Mas eles adicionaram freios para os indicadores "pesados".
Isto é ainda mais confuso.
Afinal, se o indicador não for usado pelo próprio autor, ele pode trocar como quiser e sem esperar pelo init e deinit? E o que acontecerá??? E se para uma variante de interruptor em deinit é necessário fazer algumas ações, então não faz nenhuma diferença, se for escrito para uma direção de interruptor ou para ambas as direções. Mas eles adicionaram freios para indicadores "pesados".
Onde foram adicionados os freios? Em comparação com o que eles adicionaram?
Por favor, apoie suas declarações com código, para que todos possam reproduzi-lo.
Mais uma vez. Uma vez que outra cópia do indicador é criada na mudançado símbolo-período, a ordem do OnInit no novo símbolo-período e OnDeinit no antigo símbolo-período é indefinida.
Onde foram adicionados os freios? Em comparação com o que você acrescentou?
Seja gentil o suficiente para respaldar suas reivindicações com código para que todos possam reproduzir
Mais uma vez. Uma vez que outra cópiado indicador é criada ao alterar um período-símbolo, a ordem de execução OnInit no novo período-símbolo e OnDeinit no antigo período-símbolo é indefinida.
Nesta mensagem
Se os prazos de troca forem reduzidos, então primeiro OnInit no mais jovem (novo) prazo, e depois OnDeinit no mais velho (mais velho) prazo.
Se o interruptor sobe, então é o contrário. Primeiro OnDeinit no menor (mais antigo) período de tempo, e depois OnInit no maior (mais novo) período de tempo.
Você deve ter em mente que as caches são processadas de um período de tempo de baixa ordem para um de alta ordem.
Você disse isso como é ou como você fez ao preparar a nova construção?
Se assim for, então eu entendi errado e retiro o que disse.
Nesta mensagem.
Você disse como está ou como está preparando uma nova construção?
Se como está, eu entendi mal e aceito de volta.
Isto é feito na construção 1580.
Antes disso, a desinicialização no prazo era quase sempre mais precoce. Mas somente se a chave de tempo cair, a desinicialização foi feita com o código 1, e não 3, como deveria ser
Isto é feito na construção 1580
Antes disso, a desinicialização ao mudar o cronograma era quase sempre anterior. Mas somente se a mudança de horário cair, a desinicialização foi feita com o código 1 e não 3 como deveria ser
Então, como processar esses códigos de desinicialização em Inite do indicador, o que esses códigos fazem? Como não há possibilidade de esperar no indicador, Dormir não funciona.