Seqüência de execução Init() e DeInit() - página 3
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
Tente atualizar o terminal para a versão 1065. As versões anteriores tiveram um erro de reinicialização apenas pela mudança do cronograma. Pode ajudar :)
https://www.mql5.com/ru/forum/187690
Eu tenho terminal 5.00 b1571
Você pode salvar valores de variáveis em algum lugar, em globais, por exemplo. Depois de traduzi-los, você pode ler e restaurar as variáveis.
E então a Deinit terminará seu trabalho e estragará tudo. Não faz sentido, no Init e no Deinit normais, fazer seu próprio Init e Deinit personalizados.
Eu também já encontrei este problema. (
E então a Deinit terminará seu trabalho e arruinará 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. (
Concordo plenamente (Não faz sentido no Init e no Deinit normais)
Talvez tente atribuir aos objetos gráficos um período TF como parte do prefixo de seu nome,
e depois aplicar algo como isto:
Sim, tinha que fazer algo assim, mas é uma solução parcial.
Você pode fazer o mesmo com variáveis através de um recurso ou arquivos, mas este é um recurso adicional separado, que poderia ter sido evitado com a fixação do MT5
Desorganização do código com funções laterais extras, verificações, etc. (SEM....)
Sempre pensei (acontece em vão), que quando mudo de TF, primeiro deito na antiga TF e depois inicio na nova TF. Este é um curso lógico de eventos. Confiei nesta lógica ao desenvolver Conselheiros Especializados e indicadores. E agora se revela um verdadeiro disparate com eventos que interrompem a seqüência de eventos...
Às vezes eu notei algo errado com gráficos e objetos gráficos e tive que trocar os TFs várias vezes para vê-los corretamente.
Agora são os códigos onde algo nos deinites muda e depois os deinites também mudam de volta... e acontece que a seqüência é vice versa!!! Isso é simplesmente uma lógica horrível. Quem inventou isto?
A primeira coisa que me vem à mente é que no meu deinit o estado anterior (botões pressionados/liberados) é 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 lembrei, talvez eu encontre outra coisa... estará cavando por aí amanhã.
Graças aos desenvolvedores, eles colocaram muito trabalho...
Em Deinit, escreva todos os dados para os globais. Definir um dos Globais como semáforo viaGlobalVariableSetOnCondition.
Na Init escreva que se o semáforo estiver em estado de "despejo de dados", leremos e trabalharemos ajustando o semáforo para estado de "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.
Em Deinit, escreva todos os dados para os globais. Definir um dos Globais como semáforo viaGlobalVariableSetOnCondition.
Na Init escreva que se o semáforo estiver em estado de "despejo de dados", leremos e trabalharemos ajustando o semáforo para o estado de "ler tudo".
Se o semáforo for "ilegível", então, basta esperar o retorno do semáforo (seja através de loops Sleep ou OnTimer).
O que há de tão complicado em uma implementação desse tipo? Para escrevê-lo uma vez na biblioteca e pronto.
Eu não sabia que havia tal problema. Eu esperava uma seqüência de deiniti-init e não o contrário. Quando você conhece os problemas, você pode resolvê-los. Mas me parece que deve ser resolvido no nível da lógica terminal e não com muletas, que devem ser inseridas em todos os programas agora...
Isto não é uma muleta, mas uma solução simples. A única questão é quem a implementa - os desenvolvedores ou os usuários. Em ambos os casos, você tem que gastar tempo e escrevê-lo uma vez. Se os usuários podem fazer isso, nós o escrevemos e não nos preocupamos mais em discutir a questão. Eu mesmo acabei de ler o fio e uma solução me veio imediatamente à mente. O que há para pore over? Você pode exigir algo por muito tempo, ou você mesmo pode escrevê-lo rapidamente.