Erros, bugs, perguntas - página 1930
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
Por alguma razão, tinha a certeza de que o DoubleToString não fazia sentido após a normalização. Mas não, como mostra o guião. Porque é que é assim?
Parece que a dupla -> conversão de cordas não funciona correctamente.
Resultado de uma única corrida com linhas amarelas comentadas
Resultado de uma única corrida com linhas amarelas NÃO comentadas
Abiblioteca TesterBench mostra a mesma queda no tempo de execução.
HH Não só PositionGet, mas também OrderGet, HistoryDealGet, HistoryOrderGet são lentos.
No testador (1629) as negociações são abertas a preços zero
Executar o Expert Advisor no testador utilizando carraças reais do Servidor FIBOGroup-MT5
Pergunta para programadores e colegas interessados.
No Testador em modo de visualização há um objecto da classe CiMA - muwings.
Modo = "Cada carraça baseada em carraças reais". A velocidade no Visualizador é próxima da máxima.
O problema é este. Quando uma nova barra aparece, é preciso esperar por uma carga de novos tiquetaques para actualizar os valores dos muwings CiMA, ou melhor, os valores no buffer dos muwings.
E em cada tick a actualização é acelerada pelo método CiMA::Refresh(-1).
Porque é que o Testador funciona tão mal?
Não existem tais problemas no comércio real.
A Pusha é estranha hoje em dia:
uest/302788
pedido/302788
Como posso adivinhar, fui eu que fui colocado como candidato e comentei a mesma ordem.
Mas as mensagens são como para os codificadores)
A partir da documentação
ENUM_BASE_CORNER
Identificador
Descrição
CANTO_ESQUERDA_ACIMA
Centro de coordenadas no canto superior esquerdo do gráfico
CANTO_ESQUERDA_BAIXO
Centro de coordenadas no canto inferior esquerdo do gráfico
CANTO_DIREITA_BAIXO
Centro de coordenadas no canto inferior direito do gráfico
CORNER_RIGHT_UPPER
centro das coordenadas no canto superior direito do gráfico
Pergunta: Porque não foi possível desenhar a tabela por ordem numérica? Coloca-se 1 - e em vez do esperado"centro de coordenadas no canto superior esquerdo do gráfico" obtém-se"centro de coordenadas no canto inferior direito do gráfico".
Agora é assim que parece
1 - Centro de coordenadas no canto inferior esquerdo do gráfico.
2 - Centro de coordenadas no canto inferior direito do gráfico
3 - Centro de coordenadas no canto superior direito do gráfico
4 - Centro de coordenadas no canto superior esquerdo do gráfico
A partir da documentação
ENUM_BASE_CORNER
Identificador
Descrição
CANTO_ESQUERDA_ACIMA
Centro de coordenadas no canto superior esquerdo do gráfico
CANTO_ESQUERDA_BAIXO
Centro de coordenadas no canto inferior esquerdo do gráfico
CANTO_DIREITA_BAIXO
Centro de coordenadas no canto inferior direito do gráfico
CORNER_RIGHT_UPPER
centro das coordenadas no canto superior direito do gráfico
Pergunta: Porque é que a tabela não pode estar em ordem numérica? Coloca 1 - e em vez do esperado"Centro de coordenadas no canto superior esquerdo do gráfico" obtém"Centro de coordenadas no canto inferior direito do gráfico".
Parece ser assim
1 - Centro de coordenadas no canto inferior esquerdo do gráfico.
2 - Centro de coordenadas no canto inferior direito do gráfico
3 - Centro de coordenadas no canto superior direito do gráfico
4 - Centro de coordenadas no canto superior esquerdo do gráfico
A contagem começa a partir de zero.
O que o impede de entrar CORNER_LEFT_UPPER em vez de um número? É para isso que serve a enumeração, para que não tenha de pensar em números.
No helpdesk
MT4:
Para objectos com tamanho fixo: OBJ_BUTTON, OBJ_RECTANGLE_LABEL e OBJ_EDIT propriedades OBJPROP_XDISTANCE e OBJPROP_YDISTANCE definem a posição do ponto superior esquerdo do objecto em relação ao canto do gráfico (OBJPROP_CORNER), a partir do qual serão contadas as coordenadas X e Y em pixels.
MT5:
Para objectos com tamanho fixo: OBJ_BUTTON, OBJ_RECTANGLE_LABEL, OBJ_EDIT e OBJ_CHART, as propriedades OBJPROP_XDISTANCE e OBJPROP_YDISTANCE definem a posição do ponto superior esquerdo do objecto em relação ao canto do gráfico (OBJPROP_CORNER), a partir do qual serão medidas as coordenadas X e Y em pixels.
A questão é que o antigo código do MT4 usando ObjectSet permite posicionar objectos relativamente às suas arestas (cantos) - para objectos na parte esquerda o cálculo dos pixels é efectuado a partir do primeiro símbolo, para objectos na parte direita - a partir do último símbolo, enquanto a nova versão calcula sempre o travessão a partir do primeiro símbolo, o que torna difícil o posicionamento de etiquetas com texto, porque nem sempre se sabe quantos símbolos de texto serão. Peço aos programadores que adicionem um método de alinhamento de texto à escolha!
Se alguém souber como obter alinhamento à esquerda e à direita no MT5, por favor partilhe a característica apropriada!
A contagem começa a partir de zero.
O que o impede de entrar CORNER_LEFT_UPPER em vez de um número? É para isso que serve a enumeração, para que não tenha de pensar em números.
A partir do zero? Bem, OK - que seja do zero - eu não o levei em conta - mas mesmo assim não funciona!
Porque faz mais sentido para mim e eu já o usei antes.
A partir do zero? Bem, OK - mesmo que seja do zero - não pensei nisso - mas mesmo assim não funciona!
Porque faz mais sentido para mim e já o usei antes...
Devo subir o item da lista que está a tentar identificar com o número 4, que não está lá? Torna-se zero - e tudo está no seu devido lugar.