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
3Б. Encerramento parcial através da abertura de uma meia venda - OUT.
Mau :/
Porque é que é mau? Tudo é simples, se o entendi correctamente. Se houver uma posição e OUT, houve uma diminuição no volume. Se OUT e não houver nenhuma posição, então a posição foi completamente fechada.
O mau é isto. A sua abordagem"Se OUT e houver uma posição, houve uma redução no volume. Se não há OUT e não há posição, então a posição foi completamente fechada" tem uma característica que considero incómoda, nomeadamente, a necessidade de verificar adicionalmente a existência de informação sobre a posição na base de dados do terminal de cada vez.
Todos sabemos que a informação no terminal de base fica com um certo atraso em relação à situação real. Por conseguinte, não podemos excluir situações em que o resultado da verificação é"há uma posição e está OUT", mas de facto a posição foi encerrada. Por outras palavras, é possível obter informações inexactas e utilizá-las como base para a tomada de acções erradas. Ou será necessário inventar verificações adicionais, atrasos, ou o que for conveniente.
Mas pode passar sem todos estes truques. Em particular, sem verificar a disponibilidade de posição. Para tal, é suficiente deixar uma correspondência de um para um entre o fecho da posição e a propriedade DEAL_ENTRY_OUT (correspondência - como é agora apresentada no Manual), e alocar a redução do volume da posição numa propriedade separada da transacção. Então será suficiente encontrar na história (HistorySelectByPosition) um único negócio com propriedade DEAL_ENTRY_OUT, e ter a certeza de que a posição não é reduzida, mas exactamente fechada, e que em nenhuma circunstância pode ser invertida.
O mau é isto. A sua abordagem"Se OUT e houver uma posição, houve uma redução no volume. Se não há OUT e não há posição, então a posição foi completamente fechada" tem uma característica que considero incómoda, nomeadamente, a necessidade de verificar adicionalmente a informação sobre a posição na base de dados do terminal de cada vez.
Todos sabemos que a informação no terminal de base fica com um certo atraso em relação à situação real. Por conseguinte, não podemos excluir situações em que o resultado da verificação é"há uma posição e está OUT", mas na realidade a posição foi totalmente fechada. Por outras palavras, é possível obter informações inexactas e utilizá-las como base para a tomada de acções erradas. Ou será necessário inventar verificações adicionais, atrasos, ou o que for conveniente.
Mas pode passar sem todos estes truques. Em particular, sem verificar a disponibilidade de posições. Para tal, é suficiente deixar uma correspondência de um para um entre o fecho da posição e a propriedade DEAL_ENTRY_OUT (correspondência - como é agora apresentada no Manual), e alocar a redução do volume da posição numa propriedade separada da transacção. Então será suficiente encontrar na história (HistorySelectByPosition) um único negócio com propriedade DEAL_ENTRY_OUT e saber com certeza que a posição não é reduzida, mas exactamente fechada, e que em nenhuma circunstância pode ser invertida.
Na OnTrade(), recebemos a resposta do servidor. Ou seja, se verificarmos o evento no OnTrade(), já saberemos ao certo se existe ou não uma posição. Embora possamos fornecer opções padrão tais como DEAL_ENTRY_FULLOUT (fechamento completo) ouDEAL_ENTRY_PARTOUT (fechamento parcial) para tornar tudo perfeitamente elegante.)))
Entretanto, pode fazer funções separadas, para que não tenha de introduzir "verificações incómodas" de cada vez.Embora pudesse fazer opções padrão como DEAL_ENTRY_FULLOUT ouDEAL_ENTRY_PARTOUT para tornar tudo perfeitamente elegante.)))
Essa é a questão... Não teria sequer de fazer verificações extra na OnTrade, o que continuaria a parecer complicado quando comparado com a solução proposta (FULLOUT / PARTOUT).
Tente fazer uma proposta ao Service Desk. Talvez eles o considerem e um dia o implementem.
Eu já fiz :) Como um deslize da língua... Uau, demorei uma hora a compor.
Ainda não se pode chamar a isto um erro. Mas o que se pode fazer agora que foi enviado. ))
Sim, cada período corresponde a um determinado valor. Alguém o publicou no fórum há alguns anos atrás. Pode descobrir por si próprio, executando uma linha como a que se segue:
O guião imprimirá os valores ENUM_TIMEFRAMES para todos os períodos no sistema decimal: