Características da linguagem mql5, subtilezas e técnicas - página 208
![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Aparentemente, compreendi mal a situação comercial.
A forma como a imaginei: a ordem de limite pendente foi executada por vários ofícios. Todo este tempo estava pendurado em ordens ao vivo e o campo ORDER_TIME_SETUP não era uma constante. Após a última troca, entrou na história. Nesse momento, a ORDER_TIME_SETUP tornou-se uma constante.
Ou não foi?
A ORDER_TIME_SETUP é sempre uma constante. Quando entrou para a história - ORDER_TIME_DONE apareceu.
A ORDER_TIME_SETUP é sempre uma constante. Quando foi atingido na história - ORDER_TIME_DONE apareceu.
Aqui estou agora a definir o limite do atraso. Depois mudo-o à mão e o guião e a ORDER_TIME_SETUP muda.
O que é que estou a fazer mal?
Já publicou no passado sobre casos semelhantes:
https://www.mql5.com/ru/forum/170952/page170#comment_15824249
https://www.mql5.com/ru/forum/170952/page172#comment_15829154
Aqui estou eu agora a definir um limitador atrasado. Depois mudo-o manualmente e o guião e a ORDER_TIME_SETUP mudam.
O que é que estou a fazer mal?
Não altera o tempo definido.
Já publicou no passado sobre casos semelhantes:
https://www.mql5.com/ru/forum/170952/page170#comment_15824249
https://www.mql5.com/ru/forum/170952/page172#comment_15829154
De facto, já o fiz. Mas não me consegui lembrar de todo. Acho que é um insecto.
Não sei o que vai acontecer com a execução parcial repetida.
Agora sei - neste corretor (estou inclinado para um bug no seu software) não vai mudar mais.
Por vezes é útil saber com que frequência os tiques são transmitidos.
Uma transacção CloseBy gera duas transacções. O swap da primeira (primeira posição em CloseBy) transacção contém a soma dos swaps de ambas as posições. A troca da segunda transacção é zero.
Se o encerramento parcial da posição for feito via CloseBy, então a parte restante da posição aberta é privada de swap - é zerada.
Resultado.
Portanto, pode muito bem haver uma enorme troca na posição mais pequena que nunca passou por um capotamento. E troca zero por uma posição grande que tenha rolado.
Cálculo do número de capotamentos (não a opção mais rápida).
Exemplo de utilização.
Resultado.
Uma transacção CloseBy gera duas transacções. O swap da primeira (primeira posição em CloseBy) transacção contém a soma dos swaps de ambas as posições. A troca da segunda transacção é zero.
Se o encerramento parcial de uma posição for feito via CloseBy, a parte restante da posição aberta fica privada de swap - zerada.
...
Portanto, pode muito bem haver uma enorme troca numa posição mínima que nunca passou por um capotamento. E troca zero sobre uma posição grande que tenha rolado.
Incrível!
Será devido a arredondamentos (para não perder ou acrescentar um cêntimo)?
Ou é apenas uma operação raramente utilizada, por isso não importa?
Incrível!
Será devido a arredondamentos (para não perder ou acrescentar um cêntimo)?
Definitivamente não, uma vez que os encerramentos parciais (OrderClose não OrderLots completos) irão drenar a troca em conformidade.
Ou é apenas uma operação raramente utilizada, por isso não importa?
Não creio que se tenha pensado muito nos cenários.