MetaEditor construído em 1490 - página 6
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
https://www.mql5.com/ru/forum/162399/page3#comment_3894115
Já há algum tempo, quando uma posição é virada, seu ID de posição é MODIFICADO. Isto é mostrado na ajuda. Daí as inconsistências.
Esse não é o problema.
O Service Desk disse que eles irão consertá-la, uma correção estará disponível na construção de hoje.
O Service Desk respondeu que uma correção estará disponível na construção de hoje.
1491 - não foi fixado.
Infelizmente - não.
A propósito, não está nada claro como o atual sistema de contabilidade de posição irá separar a parte da posição que fechou a posição anterior e a parte restante da nova posição (esta divisão não existe no momento). Parece que o problema é mais profundo do que pode parecer à primeira vista.
Infelizmente - não.
A propósito, não está nada claro como o atual sistema de contabilidade de posição irá separar a parte da posição que fechou a posição anterior e a parte restante da nova posição (esta divisão não existe no momento). Parece que o problema é mais profundo do que pode parecer à primeira vista.
Fórum sobre comércio, sistemas automatizados de comércio e testes estratégicos
MetaEditor construído em 1490
fxsaber, 2016.12.05 11:32
Sim, mesmo que oDEAL_ENTRY_INOUT esteja incluído no número de negócios da posição, ele não será útil a menos que você expanda ENUM_DEAL_PROPERTY_*.Mais ou menos o mesmo
Em minha opinião, pelo contrário, a enumeração não deve ser ampliada, mas abreviada. Portanto,DEAL_ENTRY_INOUT é uma entidade desnecessária que nada faz.
Aqui está um exemplo do que parece agora
IN; +1.0; ID 0
IN; +0,2; ID 0
IN/OUT; -2.0; ID 1 // uma nova posição com um novo ID foi criada, mas não há trocas nela; todas as trocas se referem à posição anterior; portanto a comissão e os swaps são 0.0
IN; +0,2; ID 1 // o primeiro comércio apareceu na lista e é o único
assim, uma parte do volume não foi movida para uma nova posição e não é exibida em nenhum lugar, portanto as trocas e comissões não serão levadas em conta para esta parte do volume na posição ID 1 (listas azuis e verdes correspondentes)
Agora como eu vejo isso, e como deve ser lógica e historicamente (qual decisão MQ tomará é o palpite de qualquer um):
IN; +1.0; ID 0
IN; +0,2; ID 0
OUT; -1,2; ID 0 // a parte do volume do negócio que foi para a posição que está sendo fechada
IN; -0,8; ID 1 // uma nova posição apareceu com o novo ID, o comércio está presente como o restante, o comércio está na lista, e é o primeiro
IN; +0,2; ID 1 // o segundo comércio da lista
Assim, o tipo de acordo IN/Out não é de todo necessário. Desta forma, tudo é considerado corretamente e as listas de acordos estão completas, podemos obter adequadamente os valores das comissões e permutas para os acordos correspondentes. E se houver a necessidade de determinar quais negócios (uma parte foi para fechar e a outra para abrir uma nova posição) fazem parte de uma ordem, será muito fácil fazê-lo - negócios OUT e IN tendo o mesmo tempo (marcados em negrito).
Em minha opinião, pelo contrário, a enumeração não deve ser ampliada, mas abreviada. Portanto,DEAL_ENTRY_INOUT é uma entidade supérflua que não faz nada.
Uma transação é uma entidade de execução que não depende de plataforma. E as bandeiras ENTRY são um disparate da MQ.
Se houvesse um comércio no mercado, você não poderia representá-lo como dois, mesmo que fosse conveniente.
A MQ se esforçou ao máximo para acrescentar a virtualização - modo Hedge. Fazer até mesmo uma simples virtualização para uma troca é uma má decisão.
Mas a ampliação das propriedades da transação proporciona conveniência sem as potenciais muletas.
Uma transação é uma entidade de execução que não depende, de forma alguma, da plataforma. E as bandeiras ENTRY são um artifício de MQ.
Se houvesse um comércio no mercado, você não poderia representá-lo como dois, mesmo que fosse conveniente.
A MQ se esforçou ao máximo para acrescentar a virtualização - modo Hedge. Fazer até mesmo uma simples virtualização para uma troca é uma má decisão.
Mas a ampliação das propriedades da transação proporciona conveniência sem muletas em potencial.
Bem, eu estava apenas expressando minha opinião.
E que tipo de extensão salvaria o dia? Você ainda precisa determinar de alguma forma qual parte da transação se relaciona com a posição antiga e qual com a nova.
E que tipo de expansão salvaria a situação? Ainda há alguma maneira de determinar qual parte do acordo é para a posição antiga e qual é para a nova.
1491 - Alpari-MT5-Demo. As telas mostram o mesmo lugar
Terminal
Verdadeiro testador de carrapatos
Os castiçais não correspondem um ao outro - no testador, eles são difusos. Além disso, o tempo histórico do testador e do terminal diferem em uma hora.
CopyTicks no terminal retorna os mesmos dados que no testador - uma hora de diferença. Portanto, os carrapatos não combinam completamente com as barras.
Então, como confiar no MT5, o testador, quando há um completo autocrédito? Por que os desenvolvedores não dispõem de EAs de referência para serem executados no testador e sabem com certeza que funciona claramente? É uma confusão completa.