Erros, bugs, perguntas - página 3131
![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Só posso responder por &= imediatamente:
MQL5 Reference Guide / Language Basics / Operations and Expressions / Assignment Operations:Em analogia com a variável cumulativa y:
Mas esta é a minha primeira experiência com &=, por isso posso estar errado.
Em primeiro lugar, todas as condições lógicas são resumidas em h_plus acumulativo dentro para e o bool-sum resultante é inserido no se que não tem nada a ver com interno para.No seu caso, não é este o caso, pois ambas as condições devem ser satisfeitas. Mas se colocar isto
então, sim. Se a condição "a" for cumprida, a segunda condição não será verificada. Isto tem sido combatido há anos, e agora está a sugerir que voltemos ao século passado.Embora... eu esteja errado nesta minha declaração. Aparentemente não percebi bem o que está aqui escrito.
Não me atrevo a chamar-lhe um insecto. É por isso que vou simplesmente dizer que notei uma peculiaridade do se operador. Suspeito que também possa ser relevante para outras línguas escritas.
Se um se revelar verdadeiro, verifique os saltos para Array[over_index] e aqui o terminal começa a colidir através da parte'array out of range', o que é bem verdade. Mas se um terminal se revelar falso, o terminal não verificará a condição de Array[over_index] e, portanto, a redundância do índice, e se irá saltar mais e o codificador não saberá que existe um array com um índice inexistente no seu programa... ou antes uma existente, mas redundante.
Talvez devesse haver uma correcção para que a verificação de "matriz fora de alcance" fosse efectuada até ao fim do laço e a mesma mensagem fosse emitida? Ou irá reduzir significativamente a velocidade do operador?
Mesmo que a && condição e a primeira condição não sejam cumpridas, a segunda não será verificada. Portanto, desculpem-me se enganei alguém...
Já tentei tanto quebrar como voltar no calor do momento, mas isso só piorou as coisas. Vou tentar simplificar um pouco mais o código e repensá-lo com pausa.
Assim.
Ao escalar o gráfico movendo o rato ao longo da linha temporal, o gráfico corre para a esquerda ou para a direita, dependendo da direcção do rato, de modo que tudo o que está no foco de visão do utilizador desaparece frequentemente apenas para além dos limites do gráfico. Isto é terrivelmente inconveniente, porque depois é preciso procurar o lugar certo, e isto tem sido assim desde que estou familiarizado com a MT.
Era lógico supor que talvez ao clicar no ícone da lupa, o gráfico será redimensionado para o centro, mas não, o comportamento é o mesmo que com a escala do rato - o gráfico move-se para a esquerda (compressão) ou para a direita (expansão).
Caros programadores! Pedimos-lhe encarecidamente que altere o comportamento de escala da carta, é necessário deixar o centro da carta no centro.
Todos com quem discuti este inconveniente de trabalhar com o gráfico concordam comigo, por isso tenho uma boa hipótese de ser objectivo em relação a este problema.
Tentou habituar-se a ele durante 14 anos - não conseguiu.
É assim.
Nova ideia, vou tentar.
Como para a opção anterior:
sem sequer o experimentar, já é claro que
é após a soma, o que significa que o terminal verá primeiro a linha anterior e compreenderá que existe uma matriz com um índice excessivo e dará a mesma mensagem de"matriz fora de alcance". Isto é a segunda coisa. E a primeira é que devemos verificar não para !h_plus mas para ArraySize(high)<=i+increment e escapar ao laço no caso de o índice ser excedido. Tentei tudo isto ontem, mas falhei em algumas subtilezas. Sim, não havia mensagem, mas o indicador também começou a fazer uma confusão.
Como para a opção anterior:
sem sequer o experimentar, já é claro que
é após a soma, o que significa que o terminal verá primeiro a linha anterior e compreenderá que existe uma matriz com um índice excessivo e dará a mesma mensagem de"matriz fora de alcance". Esta é a segunda coisa. E a primeira é que devemos verificar não para !h_plus mas para ArraySize(high)<=i+increment e escapar ao laço no caso de o índice ser excedido. Tentei tudo isto ontem, mas falhei em algumas subtilezas. Sim, o mensageiro tinha desaparecido, mas o indicador também começou a fazer uma confusão.
Portanto, o problema aqui é
i<rates_total-3
Escrevi por uma razão, e o pontapé de saída precoce do laço é precisamente para simular o cálculo if()Não me atrevo a chamar-lhe um insecto. Portanto, direi apenas que notei uma peculiaridade da declaração do "se". Suspeito que isto possa aplicar-se também a outras línguas.
Se um se revelar verdadeiro, verifique os saltos para Array[over_index] e aqui o terminal começa a colidir através da parte'array out of range', o que é bem verdade. Mas se um terminal se revelar falso, o terminal não verificará a condição de Array[over_index] e, portanto, a redundância do índice, e se irá saltar mais e o codificador não saberá que existe um array com um índice inexistente no seu programa... ou antes uma existente, mas redundante.
Talvez devesse haver uma correcção para que a verificação de "matriz fora de alcance" fosse efectuada até ao fim do laçoe a mesma mensagem fosse emitida? Ou irá reduzir significativamente a velocidade do operador?
Se definir a variável a como falsa, o controlo é transmitido e não afecta a matriz ou o código entre parênteses depois se, porque no seu caso
if(a && Array[over_index]>val) {...}
o controlo só será passado para a parte direita da condição se a parte esquerda (a) for verdadeira
se, por exemplo, fizer
if(check(over_index) && Array[over_index]>val) {...}
onde a função de verificação verifica o array Array, nunca obterá "array fora de alcance". Assim, pode verificar o índice do array e endereçá-lo num if. Mas para passar o controlo para a segunda parte do if com && operador, se a primeira parte for falsa, dificilmente será possível em qualquer uma das linguagens de programação existentes...
Existe um problema, que parece ser aleatório e ocasional.
Aparece quando se trabalha no testador com várias moedas.
Em cada ciclo solicito preços reais por símbolos. Se por alguma razão o testador não receber citações para um determinado símbolo, utiliza as citações obtidas anteriormente para outro símbolo.
Devo abrir uma posição se o preço for mais elevado do que o especificado. Devo abrir posição se obtiver dados errados de outro símbolo.
O símbolo EURCAD abre se o preço for superior a 1,45117. 1,74425>1,45117? Sim, é mais alto mas é o preço de outro símbolo.
Detectámos 7 ordens erradas em 500.
Existe um problema, que parece ser aleatório e ocasional.
Aparece quando se trabalha no testador com várias moedas.
Em cada ciclo solicito preços reais por símbolos. Se por alguma razão o testador não receber citações para um determinado símbolo, utiliza as citações obtidas anteriormente para outro símbolo.
Devo abrir uma posição se o preço for mais elevado do que o especificado. Estou a utilizar dados errados de outro símbolo para a abertura.
Símbolo EURCAD se o preço for superior a 1,45117, então abre-se. 1,74425>1,45117? Sim, é mais alto mas é o preço de outro símbolo.
Detectámos 7 ordens de erro de entre 500.
O problema está no código, mas os telepatas já estão a celebrar e, quando saírem do sono, dirão que o erro está na linha 123652
Problemas no código, mas os telepatas já estão a celebrar, e quando saírem do seu binge, dirão que o erro está na linha 123652
Não há erro no código, o código foi reescrito para eliminar o erro, e o erro não aparece regularmente, é completamente caótico