Erros, bugs, perguntas - página 2456
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
Ler Ajuda. Leia "FAQ sobre o serviço de Sinais". Ver ajuda vídeo sobre o serviço Sinais.
É melhor não abrir o Metatrader no seu telefone? Ou é irrelevante?
Pode abrir um terminal no seu PC local ou no seu telefone - precisa de monitorizar o comércio, não é verdade? O principal é não ter uma situação em que a subscrição do sinal seja ligada ao mesmo tempo em dois terminais.
Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial
Insectos, insectos, perguntas
Alexey Kozitsyn, 2019.05.03 11:24
Não é possível introduzir um ficheiro com # no seu nome em armazém. Este é um comportamento normal ou um insecto?Depois de reiniciar o PC, o projecto inclui ficheiro (*.mqh) estava completamente vazio (todos os dados foram escritos por cima de NUL (0x00)).
Mas que raio?
Fazer cópias de segurança, se a compilação de código pode deixar cair dados do utilizador para sempre, este não é o caso.
Um ficheiro com um # no seu nome não pode ser acrescentado ao armazenamento. Este é um comportamento normal ou um insecto?
Durante a compilação do projecto em ME (build 2025), Win10 falhou (sem mini-bomba).
Após reiniciar o PC, o ficheiro do projecto (*.mqh) acabou por ficar completamente vazio (todos os dados foram substituídos por NUL (0x00)).
Mas que raio?
Fazer cópias de segurança, se a compilação de código pode deixar cair dados do utilizador para sempre, este não é o caso.
Que tipo de erro foi indicado no BSOD ?
Com que frequência ocorre este comportamento?
Ouvi falar disso por um conhecido, quando trabalhava em VS, na compilação (muito raramente, não mais do que uma vez por mês) havia um BSOD, depois do qual o conteúdo dos ficheiros de origem parecia estar cheio de zeros.
Não me lembro dos detalhes, mas foi resolvido através da substituição do PC.
O compilador MQL não utiliza nenhum truque "complicado" e lê o conteúdo dos ficheiros de compilação de uma forma simples e fiável:
Se o erro ocorrer frequentemente, tente, por exemplo, desactivar o antivírus
Que erro foi indicado no BSOD ?
Muito obrigado pela sua resposta pormenorizada.
O BSOD estava na forma de um reinício do PC, por isso não há código de erro ou ficheiro minidump.
Nada de interessante nos registos de eventos (o padrão "O sistema reiniciou sem desligar limpidamente primeiro...").
O problema de limpar o ficheiro não é novo, aconteceu há 3 anos no Windwos 7, o código fonte do ficheiro mq4 foi limpo durante a compilação/debugging durante o BSOD.
Também há cerca de 2 anos atrás um utilizador relatou este problema no fórum, infelizmente não foi possível encontrar comentários.
Com que frequência ocorre este comportamento?
Sem BSOD durante cerca de 9 meses, mas este é o terceiro na última semana (uma vez BSOD com MEMORY CORRUPTION no processo de kernel, o segundo foi Windows congelado, hoje reiniciado durante a compilação/debug em MT).
Para além do skype nada de novo foi instalado, a sua remoção não ajudou.
O problema de limpeza ocorre quando um encerramento do Windows não normalizado atinge a compilação/debug de MT.
Hoje, o trabalho real foi substituído, não uma peça de código de teste como era antes (há alguns anos atrás) - por isso há uma reacção ao incidente.
Se o erro ocorrer frequentemente, tente desactivar o antivírus, por exemplo
O problema é ter este problema, não encontrar uma solução para o problema.
Vou verificar novamente como os ficheiros são guardados antes de iniciar a compilação.
Não é difícil para mim procurar por mim próprio,
Infelizmente estou completamente desprovido de conhecimentos sobre o comportamento do SO crash, por isso vamos assumir com base no resultado - todos os dados *.mqh da fonte são sobrescritos para 0x00.
O que acontece quando se compila o projecto em MT5(build 2025):
1. A primeira coisa que me chama a atenção é que eu passo por todos os separadores em ME e escrevo fluxos NTFS para cada um dos ficheiros abertos.
Tenho > 50 separadores abertos, dos quais tenho 8 ficheiros de projectos.
Como resultado para uma compilação de projecto recebemos (8 + 50) * 2 = 116 ficheiros NTFS de 440 bytes cada.
Em SSD isto leva 0,2 seg.
2. Se encontrar um ficheiro com alterações e este existir em disco, ele é substituído por novos dados da memória.
A sobreescrita tem lugar para todos os ficheiros alterados, independentemente de serem ou não deste projecto.
Muito provavelmente, como resultado do crash Windows é apagado da memória ME para fonte *.mqh, mas o thread que está a escrever para o ficheiro continua o seu trabalho.
Como resultado, ao guardar as alterações no ficheiro, o número de bytes a escrever está correcto, mas os pontos de referência para a memória já apagada, sobregravando o código fonte em \x00.
Após alterar a password da conta, não é possível iniciar sessão no metaeditor com a nova password e aceder ao repositório
Se recuperar a sua palavra-passe, pode voltar a entrar no sistema
não é uma piada ou uma história de vida, é um alerta de erro. Basta tentar alterar a palavra-passe através do sítio web e depois entrar no repositório através do metaeditor.