Erros, bugs, perguntas - página 1931
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
É sempre melhor pela manhã... :)
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 a versão antiga do MT4 usando ObjectSet permite colocar objectos relativos à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 efectua sempre o cálculo 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 função correspondente!
E não se zangue, mas leia atentamente a ajuda:
Para objectos OBJ_LABEL, OBJ_BITMAP_LABEL e OBJ_RECTANGLE_LABEL pode definir o ângulo do gráfico, relativamente ao qual o ponto de ancoragem do objecto é posicionado. Este ângulo é definido através da propriedade OBJPROP_CORNER, que pode ter um dos quatro valores da enumeração ENUM_BASE_CORNER:
Identificador
Descrição
CANTO_ESQUERDA_ACIMA
Coordenadas do ponto de ancoragem em relação ao canto superior esquerdo do gráfico
CANTO_ESQUERDA_BAIXO
As coordenadas do ponto de ancoragem são dadas em relação ao canto inferior esquerdo do gráfico
CANTO_DIREITA_BAIXO
As coordenadas do ponto de ancoragem são definidas em relação ao canto inferior direito do gráfico
CORNER_RIGHT_UPPER
As coordenadas do ponto de ancoragem são definidas em relação ao canto superior direito do gráfico
A posição do ponto de ancoragem do objecto é especificada pela propriedade OBJPROP_ANCHOR e pode ser um dos 9 valores da enumeração ENUM_ANCHOR_POINT:
Identificador
Descrição
ÂNCORA_ESQUERDA_ACIMA
Ponto de ancoragem no canto superior esquerdo
ANCHOR_LEFT
Âncora aponta para a esquerda no centro
ANCHOR_LEFT_LOWER
Ponto de ancoragem no canto inferior esquerdo
ANCHOR_LOWER
Ponto de ancoragem abaixo do centro
ANCHOR_RIGHT_LOWER
Ponto de ancoragem no canto inferior direito
ANCHOR_RIGHT
Âncora aponta para a direita no centro
ANCHOR_RIGHT_UPPER
Ponto de ancoragem no canto superior direito
ANCHOR_UPPER
Ponto de ancoragem no centro superior
ANCHOR_CENTER
Ponto de ancoragem exactamente no centro do objecto
Devo subir o item da lista que está a tentar rotular com o número 4, que não está lá? Torna-se zero - e tudo está no seu devido lugar.
Claro que mudei tudo - talvez eu seja estúpido...
E não fique zangado, leia atentamente a ajuda:
Para objectos OBJ_LABEL, OBJ_BITMAP_LABEL e OBJ_RECTANGLE_LABEL pode definir o ângulo do gráfico, relativamente ao qual o ponto de ancoragem do objecto é posicionado. Este ângulo é definido através da propriedade OBJPROP_CORNER, que pode ter um dos quatro valores da enumeração ENUM_BASE_CORNER:
Identificador
Descrição
CANTO_ESQUERDA_ACIMA
Coordenadas do ponto de ancoragem em relação ao canto superior esquerdo do gráfico
CANTO_ESQUERDA_BAIXO
As coordenadas do ponto de ancoragem são dadas em relação ao canto inferior esquerdo do gráfico
CANTO_DIREITA_BAIXO
As coordenadas do ponto de ancoragem são definidas em relação ao canto inferior direito do gráfico
CORNER_RIGHT_UPPER
As coordenadas do ponto de ancoragem são definidas em relação ao canto superior direito do gráfico
A posição do ponto de ancoragem do objecto é especificada pela propriedade OBJPROP_ANCHOR e pode ser um dos 9 valores da enumeração ENUM_ANCHOR_POINT:
Identificador
Descrição
ÂNCORA_ESQUERDA_ACIMA
Ponto de ancoragem no canto superior esquerdo
ANCHOR_LEFT
Âncora aponta para a esquerda no centro
ANCHOR_LEFT_LOWER
Ponto de ancoragem no canto inferior esquerdo
ANCHOR_LOWER
Ponto de ancoragem abaixo do centro
ANCHOR_RIGHT_LOWER
Ponto de ancoragem no canto inferior direito
ANCHOR_RIGHT
Âncora aponta para a direita no centro
ANCHOR_RIGHT_UPPER
Ponto de ancoragem no canto superior direito
ANCHOR_UPPER
Ponto de ancoragem no centro superior
ANCHOR_CENTER
Ponto de ancoragem directamente no centro do objecto
Obrigado, tentarei pensar em algo amanhã...
É sempre melhor pela manhã... :)
Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial
Insectos, insectos, perguntas
fxsaber, 2017.07.18 09:51
Quase uma pergunta infantil: porque é que é assim?Por alguma razão tinha a certeza de que a DoubleToString não fazia sentido após a sua normalização. Mas não, como mostra o guião. Porque é que é este o caso?
Parece que a dupla -> conversão de cordas não funciona correctamente.
Este exemplo é bastante complicado de entender, por isso dei-vos outro.
Eis o que quero dizer.
Строковая в double переводится без проблем. Обратно - получаем другой результат.
Ou seja, pegou na corda "8.905", converteu-a para o dobro e imediatamente para corda, obtendo 8.9049999999999999999. Mas a primeira linha do OnStart mostra que (duplo) "8.905" == 8.905. Ou seja, 8.905 deve ser impresso.
Naturalmente, a situação óbvia de fim zero não deve funcionar:
Tendo investigado um pouco o assunto, cheguei à seguinte situação
Explique por favor porque é que a conversão double -> string ainda é considerada correcta. O último exemplo está a dar-me cabo da cabeça.
Explique por favor porque é que a dupla -> conversão de cordas ainda é considerada correcta. O último exemplo é um sopro de mente tão completo.
Comentário sobre o último exemplo
Os números reais podem ser considerados idênticos se tiverem sido submetidos às mesmas conversões. Mesmo conversões aparentemente idênticas - num*0,5 e num/2,0 levam a resultados diferentes. O mesmo se pode dizer das operações de espelhamento. num*=num2, num/=num2. O número resultante não será igual ao número original. Bem-vindo ao mundo dos números reais.
Durante o processo de normalização, foram realizadas 3 operações nesta amostra com um número real - num*=1000, num+=0,5, num/=1000.
Pode verificar os passos no depurador
SD diz que é correcto neste caso.
Porque é que é confuso?
A grande maioria dos números decimais reais não são representáveis como uma fracção binária sem um resto. Colocar um formato de armazenamento duplo em cima disso e obtém-se um material tão feio.
Na verdade, o tipo decimal seria agradável, é útil.
Comentário sobre o último exemplo
Os números reais podem ser considerados idênticos se as mesmas conversões forem efectuadas neles. Mesmo conversões aparentemente idênticas - num*0,5 e num/2,0 levam a resultados diferentes. O mesmo se pode dizer das operações de espelhamento. num*=num2, num/=num2. O número resultante não será igual ao número original. Bem-vindo ao mundo dos números reais.
Neste exemplo, 3 operações - num*=1000, num+=0,5, num/=1000 - foram realizadas com um número real durante a normalização.
Pode verificar os passos no depurador
Uma explicação muito construtiva, obrigado!
Mas este contra-exemplo impressiona-me.
É assim que a normalização deve funcionar?
Porque é que é confuso?
Depois da explicação de Slava não é confusa, mas depois há um exemplo que nos faz questionar a correcção da própria NormalizeDouble.