Erros, bugs, perguntas - página 1279

 

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 )

 
sanyooooook:

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.

 
Abriram quatro terminais MT5, começaram a ser actualizados para b.1079. Carregou a actualização normalmente, foi para reiniciar normalmente. Apenas metade deles conseguiu sair da reinicialização, e isso foi por acidente.
A razão foi precisamente esta actualização. Abaixo encontra-se um gráfico do processo de actualização de um terminal MT5 com um sistema de negociação, ficheiro swap antes e depois da actualização.

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.



 
s2101:
Abriram quatro terminais MT5, começaram a ser actualizados para b.1079. Carregou a actualização normalmente, foi para reiniciar normalmente. Apenas metade deles conseguiu sair da reinicialização, e isso foi por acidente.
A razão foi precisamente esta actualização. O gráfico abaixo mostra o processo de actualização de um terminal MT5 com um sistema de negociação, ficheiro swap antes e depois da actualização.

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:

int OnInit(){
   Comment("AAAAAAAAAAAAAAAAAAAAAAAAA");
}

void OnDeinit(const int reason) {
   Comment("");
}

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

template<typename T>
string ETS( T t ) { return ( typename( t ) == "int" ? "OK" : ::EnumToString( t ) ); }
enum ENUM {     ENUM__ };
void OnStart()
{
        ENUM i1 = ENUM__;       Print( ETS( i1 )); //нормально
        int  i2 = 0;            Print( ETS( i2 )); //ошибка компиляции
}
Porquê calcular ::EnumToString( int ) no segundo caso se o tipo é conhecido no momento da compilação ?
 
ALXIMIKS:

A 90% será "".

O que era esperado? Um escreve, o outro apaga.
 
A100:
O que era esperado? Um escreve, o outro apaga.
Esqueceu-se do segundo escrito.

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

#property library
#define __MQL5
#ifdef  __MQL5
#ifndef __MQL5
#else
#else
#endif


Razão: