Erros, bugs, perguntas - página 1279
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
Ao obter o histórico de carrapatos com CopyTicks(), os carrapatos da sessão de trabalho anterior do terminal são devolvidos, o que contradiz a descrição da função:
MQL5: Добавлена функция работы с тиковой историей CopyTicks. Функция позволяет получить массив тиков, накопленных терминалом за текущую рабочую сессию. Глубина получаемых тиков ограничена последними 2 000.
Pergunta aos criadores. Será corrigido? E é possível fazer a transferência do terminal os últimos N ticks do servidor (ou corretor) MQ, quando este começará, para que não tenha de esperar pelo histórico acumulado? É pouco provável que alguém precise de uma história de carrapatos para alguns carrapatos N desconhecidos no passado. Servicedesk#1162481
Tenho a caixa de verificação "novas capturas de ecrã" removida nas minhas definições de privacidade, ou seja, não deve haver mensagens no meu feed quando estas são publicadas.
O meu feed não contém, de facto, esta mensagem. No entanto, a mensagem sobre a publicação de novas capturas de ecrã está nos noticiários dos meus amigos.
ZS: se assim deve ser, então acontece que este cenário não tem nada a ver com privacidade )
Tenho a caixa de verificação "novas capturas de ecrã" removida nas minhas definições de privacidade, ou seja, não deve haver mensagens no meu feed quando estas são publicadas.
O meu feed não contém, de facto, esta mensagem. No entanto, a mensagem sobre a publicação de novas capturas de ecrã está nos noticiários dos meus amigos.
ZS: se assim deve ser, então acontece que este cenário não tem nada a ver com privacidade )
Obrigado pela mensagem,
mensagens sobre os seus screenshots não devem estar na alimentação dos seus amigos. O erro será corrigido em breve.
Ao actualizar para b.1085, tudo permaneceu na mesma.
O que teve a ver com o terminal para ter um terminal a falhar o ficheiro swap por 2 Gb?
Não há indicadores "pesados" no sistema. O mais "pesado" leva apenas 7 µsec para carregar, dois, - 5, um, - 4, os outros, - 1 µsec ou menos.
Para comparação, o indicador JMA da CodeBase requer 110 µsec no meu computador, mas não é utilizado no sistema.
Assim, o MT5 actualizado enterrou instantaneamente o meu sistema de negociação, - impossível de funcionar mesmo num terminal, - e eu enterrei-o em conformidade.
Quando o MT5 tem uma piscina, uma loja e uma latrina numa garrafa, isso estava destinado a acontecer.
A monsterização do bom MT5 começou há muito tempo. Quando a quantidade de lixo nas versões anteriores do MT5 se aproximou de 1 Gb, fiquei preocupado e, ao mesmo tempo, mudei completamente o sistema para a plataforma MT4. Acabou por não ser em vão.
O sistema analisa simultaneamente 8 TFs, três das quais podem ser vistas no gráfico. Os principais sinais comerciais do sistema são gerados com base em medições instrumentais de
rácio oferta/procura, pelo que são objectivos.
Abaixo - 5 terminais MT4 são abertos simultaneamente (para diferentes pares de moedas) com o mesmo sistema de negociação e não há problemas, como se viu até agora.
Porque escondeu a memória física da captura de ecrã mas não se esqueceu do ficheiro swap?
Além disso, ao abordar uma questão tão importante, esqueceu-se de anexar uma captura de ecrã da secção de processos, onde pode ver tanto o consumo real de memória por processo como o número de fios em execução.
Tanto quanto percebi, o MT5 1085 tem uma condição racial para a fixação de um comentário (Comentário).
A questão é esta - existe um indicador numa janela separada com um código:
Se executarmos 2 instâncias do indicador no mesmo gráfico e mudarmos o TF, o que vemos emComentário?
Em 90% será "". (se filas diferentes em filas diferentes com prioridade diferente para definirComentário de sobOnInit eOnDeinit....)
Erro de compilação
Porquê calcular ::EnumToString( int ) no segundo caso se o tipo é conhecido no momento da compilação ?A 90% será "".
O que era esperado? Um escreve, o outro apaga.
Há dois escritos e dois apagamentos. São muito provavelmente assíncronas.
O apagamento deve ser antes da escrita, mas infelizmente não é...
O compilador não detecta o erro (o que faz - pelo menos falta o segundo #endif), o que resulta na não detecção de erros mais significativos