Seqüência de execução Init() e DeInit() - página 12
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
E é isso, as lamentações começaram...
O que você está pedindo é exatamente o que as aplicações desktop normais não têm.
O que não está no aplicativo? Sincronização? )))
Se os desenvolvedores não fizessem todas essas características que já estão "fora da caixa", os escritores dos programas MQL enfrentariam constantemente todos os encantos do desenvolvimento da área de trabalho, seja em termos de segurança ou velocidade de execução.
1. O que não está nos aplicativos? Sincronização? )))
2) Você está fazendo raciocínio não-científico sem fatos. Em MT4, os indicadores operam com OnInit() e DeInit() sucessivos. Há uma desvantagem - todos os indicadores funcionam em um único fio. Pode ser resolvido escrevendo corretamente o indicador, o que também é exigido no MT5. Embora, o MT5 não se tenha afastado dele - de qualquer forma, os indicadores de um gráfico continuam a funcionar em um só fio.1. De que sincronização você está falando!
2. No MT4, como parte da execução do código indicador, init é executado primeiro e depois deinit, o que mais você precisa!!! É a mesma coisa no MT5.
Várias pessoas já me pediram para dar um exemplo específico de uma tarefa, que é problemática para ser realizada dentro do paradigma de execução de indicadores no MT5. Haverá um exemplo ou não, um exemplo claro, não sugado do nada?
1. de que sincronização você está falando?!
Sobre a inter-treading. Até que uma thread esteja completa (a que recebeu o comando para terminar), a outra thread não começa. Ou, se tudo acontecer em um só fio, é ainda mais simples: terminar todos os programas associados ao "velho" TF e só então iniciar programas no "novo" TF.
2. No MT4, como parte da execução do código indicador, init é executado primeiro e depois deinit, o que mais você precisa?! O mesmo se passa no MT5.
Certo. Este é exatamente o caso no MT4. Mas não é assim no MT5. E é disso que se trata o assunto.
Várias pessoas já me pediram para dar um exemplo específico de uma tarefa que é problemática para realizar dentro do paradigma de execução de indicadores no MT5. Haverá um exemplo ou não, um exemplo claro, não sugado do nada?
Isso mesmo, eles não deveriam. Assim, você dirige o Comandante Total, por exemplo. Por que exigir da Microsoft que o Windows cuide da seqüência "correta" de upload/download de cópias TC para a RAM? Isso é uma preocupação do sistema operacional?
OS se importa que o TC não interfira com outros TC's e o que eles fazem lá na RAM, trocar arquivos ou qualquer outra coisa que seja seu negócio.
"Eu acho que sim!" (c) Mimino, 1977.
O que o Comandante Total tem a ver com isso? É apenas uma utilidade de baixo nível, no sentido de que opera diretamente com os recursos do sistema. No caso da MQL, a tarefa da plataforma MT é liberar o programador de aplicações de cuidados com o sistema como a sincronização - a plataforma pode fornecer isso de forma mais eficaz e de uma só vez para todos. Os programadores da MQL devem pensar na análise das cotações e estratégias comerciais. Este é o propósito da MT.
O que isso tem a ver com o intercâmbio de arquivos e dados? Considere a lógica de trabalho no contexto de um programa MQL. Ele simplesmente tenta usar os eventos OnInit/OnDeinit de acordo com seu propósito - começar corretamente a partir de um determinado estado e terminar corretamente com a salvação do estado. Se eles não são adequados para este fim, então, como já observado, para que servem? A julgar pelos argumentos dos defensores - para que pudéssemos dançar por dentro e descobrir que outras cópias foram executadas antes e depois, e a partir de que prazo e para qual delas eles trocaram? Isto tem exatamente o efeito oposto do que MQ queria alcançar - que uma cópia não saiba nada sobre a outra.
Para que uma cópia não saiba nada e não tenha que descobrir, e ainda funcione sem efeitos colaterais, o núcleo precisa saber sobre todas as cópias - tanto as que estão fechadas quanto as que estão iniciando - e proporcionar um tratamento gracioso dos eventos de init/deinit para elas em uma metáfora padrão de fila. O terminal rastreia todas as cópias de qualquer maneira, e usa a fila de eventos, mas por alguma razão o init/deinit quebra a lógica do evento.
Para queuma cópia não saiba nada e não tenha que descobrir, e ainda funcione sem efeitos colaterais, o núcleo precisa estar ciente de todas as cópias - tanto as que são terminadas como as que são iniciadas - e fornecer um tratamento gracioso dos eventos de init/deinit na metáfora padrão da fila. O terminal mantém registro de todas as cópias e utiliza a fila de eventos, mas por alguma razão o init/deinit quebra a lógica do evento.
Qual é o problema de armazenar o período em uma variável principal?
Por que seria necessário transferir uma série de dados entre execuções sucessivas do indicador em diferentes TFs?
Andrey, eu não gosto de variáveis terminais globais. Fiz experiências com eles (há muito tempo) e fiquei muito decepcionado com sua velocidade e dificuldades de sincronização. Para evitar a falta de apoio, vou tentar escrever um exemplo (um pouco mais tarde) que demonstre sua velocidade. Talvez algo tenha mudado e eu esteja errado. Mas outra coisa que eu não gosto nas variáveis globais é que elas têm sua própria vida e são absolutamente públicas. Todos podem verificá-los pressionando F3 e excluí-los. Quando há vários deles, é metade do problema, mas se todos começam a usá-los, eu pessoalmente tenho a sensação de uma bagunça na minha mesa.
Sobre a passagem das matrizes. Sim, concordo, não é necessário com muita freqüência. Mas aqui está um exemplo específico - meu indicador. Seu funcionamento interno não depende do TF selecionado, pois durante a inicialização ele baixa todo (quase todo) o TF e cria seu próprio array geral (algo como um array logarítmico de citações) e realiza alguns cálculos mais volumosos de matrizes de índice com base nele. Ao trocar de TFs, fazer uma e a mesma quantidade de trabalho de cada vez não é nada racional - haverá atrasos ao trocar de TFs. Também tenho em minha cabeça algoritmos de reconhecimento de padrões, que vou implementar, de modo que os cálculos de inicialização podem levar até vários segundos, e eu gostaria que isso acontecesse apenas uma vez e esquecê-lo.
Para que uma cópia não saiba nada e não tenha que descobrir, e ainda funcione sem efeitos colaterais, o núcleo precisa saber sobre todas as cópias - tanto as que são terminadas como as que são iniciadas - e fornecer um tratamento gracioso dos eventos de init/deinit na metáfora padrão da fila. O terminal rastreia todas as cópias de qualquer maneira, e usa a fila de eventos, mas por alguma razão o init/deinit quebra a lógica do evento.
E agora imagine que não há uma única fila de eventos, mas sim uma fila para cada período de personagem. Como muitos períodos-símbolo, tantas filas de espera.
Agora sugira a ordem na qual as filas são tratadas.
E agora imagine que não há uma única fila de eventos, mas sim uma fila para cada período de símbolo. Tantos períodos simbólicos quantos as filas de espera.
Agora sugira a ordem na qual as filas são tratadas.
1. sobre a inter-treading. Até que uma thread esteja completa (a que recebeu o comando para terminar), a outra thread não começa. Ou, se tudo isso acontecer em uma única linha, é ainda mais simples: terminamos a execução de todos os programas conectados com o "velho" TF e somente depois disso iniciamos os programas no "novo" TF.
2. Certo. É exatamente a mesma coisa no MT4. Mas não é assim no MT5. É disso que trata o assunto.
3. eu dei trabalha com objetos gráficos, nasce uma beleza: um indicador ainda existe e ainda não foi limpo, enquanto o segundo está desenhando sobre esses objetos. É assim que explicaremos ao usuário: "Ao trocar o TF você observará distúrbios de curto prazo". )))1) Deve ser feito como escrevi anteriormente: o banco de dados acumulado deve ser salvo periodicamente em um arquivo ou outro armazenamento, sem problemas - abrir arquivo, escrever, fechar. Você precisa fazer isso toda vez que atualizar esses dados ou periodicamente, não ininit e deinit. (Você economiza trabalho periodicamente quando você escreve um programa, escreve um artigo). E é impossível fazer um seguro contra falha de escrita para arquivar, às vezes para seguros em situações criticamente importantes eles fazem o seguinte: escrevem informações atualizadas em um novo arquivo, após uma escrita bem sucedida eles apagam o arquivo antigo e mudam o nome do novo arquivo como era no antigo.
2) Eu já expliquei isso. Cada indicador deve trabalhar com seus próprios objetos gráficos. É claro, temos que verificar a existência dos objetos e se eles já existem, temos que acrescentar 1 ao nome do objeto.
3) Bem, você já escreveu que ele é solvível.
E estes não são problemas de forma alguma. Esta é a operação normal dos programas - criação de objetos únicos, economia periódica de informações acumuladas, limpeza após a conclusão.
1. estes são seus desejos. Mas você disse que queria a forma como os aplicativos desktop funcionam, então a forma como você quer que os aplicativos desktop não funcionem.
O que você chama de aplicações desktop? Parece que o MT5 não é uma aplicação desktop.
2. Não invente histórias. A seqüência de oninit e ondeinit é a mesma em MT4 e MT5. Não existe tal coisa como um programa que começa com o deinit.
Eu não estou inventando isso. Este é o tópico da linha atual. A questão é que o MT5 pode executar o Init para o indicador que ainda não tenha o DeInit. Sim, é. Você ainda não leu o tópico?
3) OK, vamos analisar os exemplos:
1) Para fazer o que escrevi anteriormente: o banco de dados acumulado deve ser salvo periodicamente em arquivo ou outro armazenamento, sem problemas - arquivo aberto, escrito, fechado. Você precisa fazer isso toda vez que atualizar esses dados ou periodicamente, não ininit e deinit. (Você economiza trabalho periodicamente quando você escreve um programa, escreve um artigo). E é impossível fazer um seguro contra falha de escrita para arquivar, às vezes para seguros em situações criticamente importantes eles fazem o seguinte: escrevem informações atualizadas em um novo arquivo, após uma escrita bem sucedida eles apagam o antigo, e mudam o nome do novo arquivo como era no antigo.
Tente atualizar o mesmo arquivo várias vezes por segundo e compartilhe seus sentimentos.
2) Eu já expliquei isso. Cada indicador deve trabalhar com seus próprios objetos gráficos. É claro, temos que verificar a existência dos objetos e se eles já existem, temos que acrescentar 1 ao nome do objeto.
O que isso tem a ver com a adição de 1 ao nome? Trata-se do fato de que existem objetos gráficos do mesmo indicador, mas com cópias diferentes na tela ao mesmo tempo. Tecnicamente, não há conflito. Haverá um conflito para o usuário que vê a decepção na tela até que a cópia antiga seja apagada.
3) Bem, você já escreveu que ele é solvível.
Isto não é problema algum. Esta é uma operação normal do programa - criação de objetos únicos, economia periódica das informações acumuladas, limpeza após a conclusão.