Seqüência de execução Init() e DeInit() - página 4
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
Em Deinit, escreva todos os dados para os globais. Definir um dos Globais como semáforo viaGlobalVariableSetOnCondition.
Na Init escreva que se o estado do semáforo for "despejado", então leia e trabalhe ajustando o semáforo para "ler tudo".
Se o semáforo for "ininteligível", então, basta esperar pelo semáforo (seja através de um looped Sleep ou OnTimer).
Se não houver nenhum semáforo, significa que começamos pela primeira vez e contamos tudo e ao mesmo tempo criamos um semáforo para a mudança não-futuro do TF.
O que há de tão complicado em uma implementação desse tipo? Para prescrever uma vez com uma biblioteca e pronto.
Se o sono funcionasse em indicadores, seria mais fácil. Dormir não funciona em indicadores.
Se você multiplicar o número de pessoas pequenas, que - cada uma por si, uma e outra vez - resolverá um problema comum, então as horas-homem desperdiçadas muitas vezes (no limite, um número infinito de vezes ;-)) excedem o tempo necessário para qualquer variante de edição no próprio terminal. Mesmo a presença de uma hipotética biblioteca não garante que todos estarão cientes de sua existência e da necessidade de utilizá-la. Em geral, não está claro por que fazer e deixar tal "ancinho"?
Portanto, não é um ancinho, é um comportamento lógico quando a nova cópia do indicador não sabe sobre o antigo. Isto é lógico!
Mas UM MOMENTO de pessoas quer funcionalidade adicional para que a cópia saiba! Então o que impede que estas unidades escrevam uma solução uma vez e a utilizem?
Por que fingir se importar com outras pessoas? Quem realmente precisa dela, procurará primeiro uma solução. E se não o fizerem - eles tentarão escrever um. Uma base de código centralizada serve exatamente a esse propósito.
Se o sono funcionasse em indicadores, seria mais fácil. Dormir não funciona em indicadores.
Portanto, não é um ancinho, é um comportamento lógico quando a nova cópia do indicador não sabe sobre o antigo. Isto é lógico!
Mas UM MOMENTO de pessoas quer funcionalidade adicional para que a cópia saiba! Então o que impede que estas unidades escrevam uma solução uma vez e a utilizem?
Por que fingir se importar com outras pessoas? Quem realmente precisa dela, procurará primeiro uma solução. E se não o fizerem - eles tentarão escrever um. Uma kodobase centralizada serve exatamente a esse propósito.
Não, não é tão simples assim. Os indicadores estão dentro de outra entidade - um gráfico/chart, e estão subordinados a ela (estou ciente de sua complexa relação um-para-muitos, mas isso não muda a essência). Um gráfico tem seu próprio ciclo de vida, que inclui algum tipo de init e eventos deinit internos, que são os limites para o ciclo de vida dos indicadores. Em outras palavras, um indicador não pode viver mais do que sua tabela. O deinit do gráfico deve esperar pelo deinit ou timeout do deinit de todos os indicadores. Somente então o init gráfico para o novo cronograma pode ser iniciado, e a partir dele os inits de indicadores anexos podem ser chamados.
Um ancinho é, por definição, algo que pode ser pisado. Já pisado. Um bom software não permite, em princípio, o rake.
Portanto, não é um ancinho, é um comportamento lógico quando a nova cópia do indicador não sabe sobre o antigo. Isto é lógico!
Mas UM MOMENTO de pessoas quer funcionalidade adicional para que a cópia saiba! Então o que impede que estas unidades escrevam uma solução uma vez e a utilizem?
Por que fingir se importar com outras pessoas? Quem realmente precisa dela, procurará primeiro uma solução. E se não o fizerem - eles tentarão escrever um. Uma kodobase centralizada serve exatamente o mesmo propósito.
Como é que você não sabe quando você muda os prazos e insere os parâmetros de entrada novamente?
E então a Deinit terminará seu trabalho e estragará tudo. Não faz sentido no Init e no Deinit regulares se você faz seu próprio Init e Deinit personalizados.
Eu também já encontrei este problema. (
Já lhes contei tudo, mas acrescentarei mais o meu próprio.
A peculiaridade de todos os programas para MT é que eles funcionam com base em eventos. O OnInit e o OnDeinit funcionam de forma lógica e adequada de acordo com o modelo do evento.
Mas há uma estranha nuança de comportamento das variáveis de entrada: todos os indicadores básicos, incluindo os terminais internos e os que estão incluídos na entrega padrão - cada vez que são iniciados com os mesmos parâmetros de entrada que têm sido chamados desde o início anterior. É muito conveniente. Mas não existe tal coisa para indicadores personalizados e todos os Expert Advisors e scripts incluindo os padrões, isto é algum inconveniente(desejo ao MQ: adicionar o mesmo comportamento para variáveis de entrada que para indicadores padrão).
E no que diz respeito ao trabalho com o Init e o Deinit, portanto, pessoalmente, nunca estabeleci razões para a desinicialização de programas ao trabalhar com variáveis globais de programa, sempre construo lógica sob a idéia específica do programa. Por exemplo, muitas vezes é necessário salvar variáveis globais de um programa após a desinicialização de um EA (as razões podem ser diferentes, por exemplo, a mesma desconexão causa o OnDeinit e o subseqüente OnInit), então por que eu deveria recalcular tudo e criar novas alças indicadoras, etc.?
É por isso que, como escrevi antes e fxsaber, se você precisar salvar variáveis globais de um programa em alguns casos - você pode fazer isso em variáveis globais do terminal usando as bandeiras apropriadas.
Na MQL nem tudo é liso, infelizmente, mas o trabalho do OnInit e do Ondeinit é lógico e compreensível, portanto, é uma perda de tempo).
O que você quer dizer com "não sabe", quando você muda os parâmetros de entrada, você re-insere os parâmetros de entrada?
Mas o funcionamento do OnInit e do Ondeinit é lógico e compreensível, portanto não há necessidade de fazer um grande negócio).
Favor explicar a lógica da seqüência de OnInit e OnDeinit no indicador quando você mudar o período de tempo. Eu ficaria muito grato. E eu acho que não sou o único.
Favor explicar a lógica da seqüência de operações OnInit e OnDeinit no indicador quando você mudar o período de tempo. Eu ficaria muito grato a você. E eu acho que não sou o único.
O Sr. Slava disse-o claramente.
Uma cópia do indicador é criada e o antigo é descarregado após algum tempo.
Se quisermos salvar variáveis globais do programa, devemos cuidar dele já no momento da chamada ao OnInit (as variáveis globais do terminal do cliente são boas para este fim).
E os buffers indicadores serão recalculados de qualquer forma, porque as barras (castiçais) mudaram, aparentemente, é por isso que acontece desta forma (a cópia será iniciada e a instância indicadora anterior será terminada pelo terminal).
Se o desenvolvedor do indicador vê o problema em trabalhar com objetos gráficos, então no início do indicador é necessário ligar os nomes dos objetos gráficos ao nome de TF, então a nova cópia do indicador criará novos objetos, e a cópia anterior do indicador limpará os objetos antigos.
Não há problema algum.
Fórum sobre comércio, sistemas automatizados de comércio e teste de estratégias comerciais
Seqüência de execução Init() e DeInit()
Slawa, 2017.04.07 15:31
Que tipo de lógica isso estraga tudo?
Quando você muda o prazo, é criada uma nova cópia do indicador, que nada sabe sobre a cópia anterior. Durante algum tempo (muito pouco tempo), 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
O Sr. Slava disse-o claramente.
Uma cópia do indicador é criada e o antigo é descarregado após algum tempo.
Se quisermos salvar variáveis globais do programa, devemos cuidar dele já no momento da chamada ao OnInit (as variáveis globais do terminal do cliente são boas para este fim).
E os buffers indicadores serão recalculados de qualquer forma, porque as barras (castiçais) mudaram, aparentemente, é por isso que acontece desta forma (a cópia será iniciada e a instância indicadora anterior será terminada pelo terminal).
Se o desenvolvedor do indicador vir o problema em trabalhar com objetos gráficos, então quando você iniciar o indicador, você deve amarrar os nomes dos objetos gráficos ao nome da TF, então a nova cópia do indicador criará novos objetos, e a cópia anterior do indicador limpará seus dados.
Não há nenhum problema.
Sim, é compreensível. Eu estava perguntando sobre a lógica da seqüência de execução. A questão é que não existe tal lógica. Algumas vezes OnDeinit é executado primeiro (como deveria ser de acordo com a lógica do homem comum), e outras vezes OnInit é executado primeiro.
Entendo que a resposta está na observação"Durante um certo período de tempo (um tempo muito curto) ambas as cópias do indicador existem em paralelo". Mas isto não torna a questão mais clara.