Erros, bugs, perguntas - página 2342
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
Os recursos são limitados a este tamanho?
Portanto, faz tanto mais sentido condensar os dados que estão a ser transmitidos.
Nesse sentido, o MT4 foi muito mais sábio do que o MT5 - não houve nenhuma falha de programa e foi possível analisar o LastError.
Primeiro: continuar a executar o programa após a ocorrência de um erro crítico irrecuperável não é sabedoria, mas estupidez.
Segundo: Não tenho de imprimirError() no MetaTrader 4 765x32 depois de o ter executado
Terceiro: Se remover rígido, atingiu-o, mas GetLastError() devolve 0, por isso não é claro o que analisar
Como notificar o utilizador sobre a paragem da EA?
Neste sentido, o MT4 foi muito mais sábio do que o MT5 - não houve nenhuma falha de programa e foi possível analisar o LastError.
E ao aceder a uma matriz, não será lógico verificar o índice de acesso?
Primeiro: é estupidez, e não sabedoria, continuar a executar o programa após a ocorrência de um erro crítico irrecuperável.
Em segundo lugar, depois de executar isto em MetaTrader 4 765x32, PrintError() nunca entra em jogo.
Em terceiro lugar, se removeres o estrito, ele retornará 0, mas GetLastError(), por isso não é claro o que analisar.
Não houve tarefa para mostrar que o MT4 é melhor do que o MT5. Tive de resolver um problema prático.
Fórum sobre comércio, sistemas de comércio automatizados e testes estratégicos
Bibliotecas: HistoryTicks
fxsaber, 2018.12.10 13:55
Receba uma mensagem de que a EA parou devido a uma série fora de alcance(não por culpa do autor da EA). Por exemplo, devido a falta de memória ou outras falhas. Isto significa que saberá de imediato que a EA parou anormalmente, em vez de a notar acidentalmente algumas horas mais tarde.
É desagradável quando o Expert Advisor pára, mas não é reportado de forma alguma.
E ao aceder a uma matriz, não seria lógico verificar o índice de acesso?
Não é lógico.
Assim, é ainda mais razoável condensar os dados que estão a ser transmitidos.
Verificado, 60Mb é facilmente escrito (MT4/5) em Recursos. Portanto, se existe um limite, este é mais elevado.
Um pequeno ponto, mas ainda assim.
Ao enviar para o Armazém - o primeiro painel "Fixação" - funciona bem, e o segundo, a confirmação, no meu primeiro caso, não espera pela chave OK, mas sai imediatamente, e em segundo lugar - não mostra todos os ficheiros enviados. Verifiquei no entanto - os ficheiros são enviados normalmente.
É impressão minha?
Parece estar correcto - quando após o envio de uma lista de ficheiros enviados é apresentada uma confirmação de que tudo correu bem.
Não faz sentido.
E porquê?
Parece-me que não precisamos de verificar o índice nos locais onde, logicamente falando, não há forma de aparecer um índice que vá além dos limites da matriz. E mesmo neste caso deve usar ASSERT, por precaução.
E nos locais onde o índice depende de acções anteriores relacionadas com parâmetros externos, citações e acções do utilizador, a verificação da referência do índice deve ser obrigatória.
Na sua opinião, não é assim?
E porquê?
Parece-me que não há necessidade de verificar o índice onde, com base na lógica do programa - não há maneira de um índice aparecer fora da matriz.
Concordo.
E mesmo neste caso terá de utilizar o ASSERT só por precaução.
Discordo, uma vez que a legibilidade do código sofrerá muito.
Nos locais em que o índice depende de acções anteriores relativas a parâmetros externos, citações e acções do utilizador, a verificação do índice de tratamento deve ser obrigatória.
Não compreendo o que queremos dizer aqui com parâmetros externos. Cada vez que verificar que o ArrayResize ou o ArrayCopy completaram normalmente e não a memória trivial a esgotar-se, irá inchar o código através do ASSERT, e isto é realmente uma confusão. Se não o verificar, terá uma paragem imperceptível do Expert Advisor. Até agora, encontrei apenas uma solução - substituir o ArrayResize e o ArrayCopy.
Quem está no caminho?
ChartSaveTemplate(chart_id,"\\Files\\MyPreferredTemplates\\cewl.tpl");
A função não cria uma pasta, apenas escreve um modelo se já existir uma pasta .... Se a pasta não existir, erro 4112
Portanto, as pastas devem ser preparadas de antemão.
É interessante, a função FileOpen não pode criar uma pasta na pasta modelo e a função ChartSaveTemplate não cria directórios...
Ou seja, se quiser guardar modelos em subpastas, então crie pastas manualmente....
fora de memória
na procura de GlobalVariables
pode surgir?