Erros, bugs, perguntas - página 2342

 
fxsaber:
Os recursos são limitados a este tamanho?

Portanto, faz tanto mais sentido condensar os dados que estão a ser transmitidos.

 
fxsaber:

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

 
fxsaber:
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?

 
A100:

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.

Georgiy Merts:

E ao aceder a uma matriz, não seria lógico verificar o índice de acesso?

Não é lógico.

 
Nikolai Semko:

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.

 
fxsaber:

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?

 
Georgiy Merts:

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.

 
Slava:

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?