Novo MetaTrader 4 Terminal de Clientes 387 e MetaTrader 4 Data Center construído 387 - página 11
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
Portanto, o que Slava está tentando dizer é que a construção 225 mostra exatamente o mesmo efeito com a remoção das borboletas.
Por favor, verifique seu código cuidadosamente. Aparentemente, não há nenhum efeito da reinicialização dos amortecedores.
Obrigado. Vou dar uma olhada.
O recálculo com o número errado de barras apontado por AlexSTAL foi corrigido. Mas este é um bicho muito antigo.
Obrigado por verificar, agora está claro onde cavar.
Tentaremos encontrá-la, consertá-la e emitir uma atualização o mais rápido possível.
E os gráficos off-line? Ao atualizar gráficos off-line usando PostMessageA(hwnd,WM_COMMAND,33324,0); a reinicialização ocorre em cada tick artificial!!!
Também está ocorrendo uma atualização completa. Comando de atualização
Está ocorrendo uma atualização completa. O comando Refresh
Uma atualização completa é realizada ali. Comando de atualização
Isto nunca tinha acontecido antes. Meu indicador deixou de funcionar com otimização. Agora tenho que preencher os amortecedores para cada carrapato desse tipo. Escreveu sobre isso acima.
Agora a atualização da janela limpa os amortecedores indicadores.
Estranho.
Começou ontem a verificar 229 construções depois que Slava afixou os logs. Houve o mesmo erro que em 388. Também tenho as mesmas imagens de colisão em 229 edifícios.
O principal não são as borboletas. O ziguezague desapareceu, ou seja, os amortecedores foram zerados. É por isso que as construções gráficas estavam desaparecendo.
Decidi refletir sobre isso. Hoje eu tentei novamente. Também coloquei um indicador com as configurações padrão. Funciona bem tanto nas construções 229 como nas 388. A única diferença em relação ao teste de ontem é esta. Decidi testá-lo desde versões antigas para analisar qual versão o erro apareceu. Todas as versões do indicador funcionam corretamente. Sem erros. Os amortecedores não são reinicializados. Eu ainda não encontrei isto.
O indicador não funciona com variáveis globais. Ele não guarda informações para a próxima sessão em variáveis globais. Portanto, versões antigas, lançadas primeiro para testes, não podiam deixar nenhuma informação no terminal que pudesse afetar a operação de versões lançadas posteriormente do indicador.
Pode haver algo de errado com seu computador? Mas como o computador pode afetar o funcionamento do terminal? Afete-o de tal forma que, durante os testes, os amortecedores são reinicializados em pontos aleatórios no tempo. É um mistério.
Agora os testes na construção 388 estão funcionando sem problemas com absolutamente os mesmos dados iniciais de ontem, quando houve falhas.
Estranho.
Começou ontem a verificar 229 construções depois que Slava afixou os logs. Houve o mesmo erro que em 388. As mesmas imagens de impacto saíram também na construção do 229.
Quando PPC e eu estávamos testando o ZigZag, tropeçamos em um grande número de falhas relacionadas especificamente com o ponto de partida da construção do ZigZag.
Provavelmente, apenas uma combinação de fatores - ponto de partida, número de barras, etc.
Isto nunca tinha acontecido antes. Meu indicador deixou de funcionar com otimização. Agora tenho que preencher os amortecedores para cada carrapato desse tipo. Escreveu sobre isso acima.
Agora a atualização da janela limpa os buffers indicadores.
Isto não aconteceu porque havia um bug com a contagem do contador de mudanças. Uma anulação total significa que alguns dados dentro do buffer podem ter mudado. Não podemos garantir a integridade dos dados no gráfico off-line.