Precisa da ajuda de programadores e programadores MT4 - página 7

 

Que monte de lixo...

Também penso que o looping do EA é uma tonelada de mauvais. A alteração de parâmetros apenas após o fim do ciclo inicial é perfeitamente lógica. O iniciador do tópico não pôde deixar de compreender que o problema está no seu interminável loop, pois não é um amador. No entanto, não escreveu nada no primeiro post sobre loop infinito no Expert Advisor. Pessoalmente, não implementei tais sistemas nos meus EAs, mas, tanto quanto sei, a julgar pelos meus cargos,isso nunca aconteceu antes- a janela de parâmetros nos EAs em loop não foi simplesmente aberta. Isto significa que a afirmação do TC"Leva à incompatibilidade fundamental dos EAs existentes com as novas construções de MT4" não é verdadeira - em construções antigas de MT4, tais EAs também não permitiam alterar parâmetros, porque era impossível abrir a janela até ao fim do ciclo.

EventSetMillisecondTimer resolve de facto o problema. Mas há quanto tempo apareceu esta função? Não havia apenas o EventSetTimer antes? Com um intervalo mínimo de chamada de 1 segundo tal evento é completamente inútil quando se escrevem sistemas para comércio real, quando pode haver dezenas de carraças para cada símbolo por segundo.

Ainda não há qualquer referência a esta função naajuda sobre temporizadores! Acabei de o descobrir por acidente, como uma dica ao entrar no EventSet.

 
Há, contudo, na minha opinião, no que respeita à inicialização de variáveis, um problema e uma inconsistência na nova MQL 4/5: Quando a deinicialização e inicialização não eliminam e recriam objectos dinâmicos em variáveis globais. Ou seja, se os parâmetros da EA forem lidos nos construtores de objectos criados dinamicamente em variáveis globais e a EA continuar a trabalhar com eles, quando os parâmetros forem alterados, a EA continuará a funcionar como se os parâmetros não tivessem sido alterados. Na minha opinião, não é lógico e as variáveis globais devem ser desinicializadas após a EA ser deinicializada e depois reinicializada antes da EA ser iniciada. Isto é actualmente resolvido colocando a inicialização e eliminação de tais variáveis no OnInit e OnDeinit
 
AntFX:
Há, no entanto, na minha opinião, um problema e uma inconsistência no novo MQL 4/5: Quando se deinicializa e inicializa não há eliminação e recriação de objectos dinâmicos em variáveis globais...
Este é um bom ponto... mas aparentemente o programador decidiu que apenas o "nascimento" e "morte" do programa pode afectar o valor inicial das variáveis globais... por isso, no bloco de desinicialização temos de repor os valores das variáveis globais a zero ou atribuí-los aos valores iniciais ....
 
AntFX:
Há, no entanto, na minha opinião, um problema e uma inconsistência no novo MQL 4/5: A desinicialização e inicialização não remove e recria objectos dinâmicos em variáveis globais. Ou seja, se os parâmetros da EA forem lidos nos construtores de objectos criados dinamicamente em variáveis globais e a EA continuar a trabalhar com eles, quando os parâmetros forem alterados, a EA continuará a funcionar como se os parâmetros não tivessem sido alterados. Na minha opinião, não é lógico e as variáveis globais devem ser desinicializadas após a EA ser deinicializada e depois reinicializada antes da EA ser inicializada. Isto é actualmente resolvido colocando a inicialização e eliminação de tais variáveis no OnInit e OnDeinit

Sim, é um verdadeiro ancinho, especialmente tendo em conta que a documentação (nemaqui nemaqui) não sublinha que o carregamento não está agora ligado 1 a 1 com o evento de inicialização. Aqui estão algumas palavras como esta:

As variáveis globais são inicializadas uma vez imediatamente após o programa ser carregado na memória do terminal do cliente.

não é claramente suficiente para chamar a atenção do programador para o facto de que alterações subsequentes de parâmetros irão desinicializar e inicializar, MAS NÃO efectuar a descarga e o carregamento correspondentes.

 
marketeer:

Sim, é um verdadeiro ancinho, especialmente tendo em conta que a documentação (nemaqui nemaqui) não sublinha que o carregamento não está agora ligado 1 a 1 com o evento de inicialização. Aqui estão algumas palavras como esta:

As variáveis globais são inicializadas uma vez imediatamente após o programa ser carregado na memória do terminal do cliente.

não é obviamente suficiente para chamar a atenção do programador para o facto de que alterações subsequentes de parâmetros irão desinicializar e inicializar, MAS NÃO efectuar a descarga e o carregamento correspondentes.

Não há necessidade de carregar/descarregar e reinicializar as variáveis. O programador tem de se ocupar da inicialização das variáveis.

 
Contender:

Não há necessidade de carregar/descarregar e reinicializar variáveis. O programador tem de se ocupar da inicialização de variáveis.

É isso que quero dizer: não se diz claramente quando esta mesma inicialização é feita. Código com uma variável global:

int x = 0;

isto também é inicialização. Mas não está claramente escrito na documentação que isto simplesmente não é inicialização do ponto de vista da MC.

 
A rigor, existem agora 2 inicializações diferentes em MT: uma efectuada quando o programa é carregado, e outra quando o "ambiente" é alterado quando o OnInit é chamado. Já é mau o suficiente que isto tenha de ser desenterrado.
 
marketeer:
A rigor, existem agora 2 inicializações diferentes em MT: uma é realizada no arranque do programa e a outra é realizada quando se altera o "ambiente" no momento da chamada OnInit. O mau é que isto tem de ser desenterrado.

Um arranque a frio é feito quando o programa é iniciado. A memória é atribuída às variáveis e rubricada com valores iniciais.

Quando em funcionamento - arranque a quente. Aqui o programador tem de se ocupar da inicialização das variáveis e isto é bom.

 
Contender:

Um arranque a frio é feito quando o programa é iniciado. A memória é atribuída às variáveis e rubricada com valores iniciais.

Quando em funcionamento - arranque a quente. Neste caso, o programador tem de se ocupar da inicialização de variáveis, o que é bom.

Bom ou mau, é uma questão filosófica... Mas o facto de haver informação 0.0 sobre ela na Documentação não é bom...
 
denkir:
Se é bom ou mau, é uma questão filosófica... Mas o facto de haver informação 0.0 sobre ela na Documentação não é bom...

E, se bem me lembro, antes não existia tal coisa, ou seja, para o dizer de forma suave, uma "característica" acrescentada especialmente para "conveniência" dos programadores, mas que viola a invariância dos códigos existentes (escrita para regras de inicialização anteriores). Assim, o princípio imutável de preservar a compatibilidade do código antigo com as novas versões de software sempre que possível não é observado.

Ninguém é contra as novas características e optimizações. Mas porque não fazê-los de tal forma que o código antigo não seja quebrado? Em particular, para esta nova inicialização poderíamos atribuir um comando de pré-processador adicional semelhante ao #propriedade estrita. Por exemplo, poderia ser #property lazyinit, e se for especificado pelo desenvolvedor (ou seja, explicitamente, o que significa que ele está ciente de uma nova inicialização em mql), então regozijamo-nos com a optimização da optimização. E se não for especificado, então estamos satisfeitos por o código anterior funcionar consistentemente, sem qualquer escavação e procura de locais onde as variáveis globais pudessem permanecer, que agora não só têm de ser declaradas, como também inicializadas separadamente no OnInit. Para cada uma destas variáveis, haverá 2 linhas de código em vez de uma.