Processamento OnTradeTransaction - 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
Boa tarde.
Ninguém se sente intimidado por ninguém.
Você não tem switch(trans.type)
Bem, é claro que o caso dado está em switch(trans.type). Como havia outro caso, eu não queria mostrar todo o código para não sobrecarregá-lo com informações desnecessárias.
fxsaber , obrigado pelo exemplo!
Alexey, é exatamente a mesma coisa. Estou usando 2 robôs diferentes para comercializar no mesmo símbolo em modo de rede. Os 2 cargos que você citou se complementam.
É interessante resolver o problema a partir do gatilho primário da mudança - onTradeTransaction.
Total de problemas atuais encontrados:
1. deal_add desencadeia, mas sem pose. Nenhuma reflexão até agora.
2. deal_add é acionado, mas a ordem está na terceira dimensão. Colocando um deslize, os últimos dois dias parecem ajudar. O pedido consegue chegar à história em 1 segundo. Eu não tenho robôs comerciais de alta freqüência e não uso ordens de mercado, portanto, esta solução seria apropriada.
3. deal_add é acionado 2 vezes, ou seja, um e o mesmo deal_add é acionado 2 vezes. Isto pode ser resolvido verificando o ticket de um negócio anterior e comparando-o com o atual.
Há ainda o ponto 1. explicações para isso.
Ontem eu estabeleci o limite de venda, funcionou, o deal_add veio, mas a posição não apareceu e abrimos uma ordem de parada por nada. Comecei a olhar para a descrição da transação e vi que o tipo de transação é DEAL_TYPE_SELL mas o tipo de ordem é ORDER_TYPE_BUY. Ao mesmo tempo, o bilhete de pedido é nosso. Não parecia ser muito lógico. Decidi verificar se o tipo de ordem e o tipo de comércio devem ser os mesmos na OnTradeTransaction, se o tipo de ordem e o tipo de comércio devem ser os mesmos.
Coloquei o robô na demonstração e consegui outra transação semelhante, mas desta vez a posição mudou. Mas devido à nossa verificação, a ordem de parada não foi executada. O que está acontecendo?
Vou lhe dizer imediatamente, isto é o que está vindo para o terminal. Sem que eu o invente.
Ontem eu coloquei sell_limit, ele acionou, deal_add veio, mas nenhuma posição apareceu e abrimos ordens de parada por nada. Comecei a olhar a descrição da transação e vi que o tipo de transação é DEAL_TYPE_SELL e o tipo de ordem é ORDER_TYPE_BUY. Ao mesmo tempo, o bilhete de pedido é nosso. Não parecia ser muito lógico. Decidi verificar se o tipo de ordem e o tipo de transação devem coincidir na OnTradeTransaction na transação deal_add.
Mas aqui vale a pena reler a ajuda"Estrutura das transações comerciais" - em termos de quais campos são preenchidos para o tipo deal_add.
E tomar as propriedades da ordem não da transação (onde não são preenchidas, mas zeros também correspondem a alguns valores em enumeração), mas da própria ordem, se ela estiver disponível no momento (e não no processo de transição das ordens para a história).
Isto facilita a análise de como as coisas estão indo.
Você pode acrescentar que, junto com as transações, o status das posições, ordens atuais e histórico de negociações também podem ser registrados. Então, o quadro completo estará disponível.
É aqui que vale a pena reler a ajuda"Estrutura de uma transação comercial" - em termos de quais campos são preenchidos para o tipo deal_add.
E tomar as propriedades do pedido não da transação (onde eles não são preenchidos, mas zeros também correspondem a alguns valores do tipo enumeração), mas do próprio pedido, se ele estiver disponível atualmente (e não no processo de transição dos pedidos para o histórico).
Concordo, eu estava ciente disso, mas não prestei atenção. Obrigado por me lembrar.
Entretanto, o problema de uma posição não aparecer em um caso e aparecer em outro caso permanece e não é claro.
Илья Ребенок:
No entanto, o problema com a posição não aparecendo em um caso e aparecendo no outro permanece e não é claro.
A posição foi ticada na transação, mas a posição não existia antes e não apareceu? Isto tem que ser resolvido.
A posição foi ticada na transação, mas a posição não estava lá antes e não apareceu? Isto precisa ser resolvido.
a posição não estava lá antes
a posição não estava lá antes
Havia um bilhete de posição na transação?
Havia um bilhete de posição na transação?
No posto acima, devo ter feito um pequeno mal-entendido. Havia uma posição, depois foi fechada por ordens de parada. Ou seja, o número de posições passou a ser 0. Então, uma troca foi acionada, mas a posição não apareceu.
Acho que é isto que você quer dizer. A transação continha informações sobre o bilhete da posição, mas este bilhete = bilhete da ordem anterior. Como deveria estar em modo de rede, se entendi corretamente.
Position: 82675534No posto acima, devo ter feito um pequeno mal-entendido. Havia uma posição, depois foi fechada por ordens de parada. Ou seja, o número de posições passou a ser 0. Então, uma troca foi acionada, mas a posição não apareceu.
Acho que é isto que você quer dizer. A transação continha informações sobre o bilhete da posição, mas este bilhete = bilhete da ordem anterior. Como em geral, deveria estar em modo de rede, se eu entendi corretamente.
Se a posição sobre o símbolo (cumulativo, todos os robôs e operações manuais juntos) tornar-se 0,0, a próxima transação abrirá (DEAL_ENTRY_IN) uma nova posição, com um novo bilhete (==ticket de ordem).
Na verdade, parece-me que quando se faz a compensação, não há necessidade de olhar a posição de forma alguma - cada robô tem que responder por "sua" - como os resultados das negociações em suas ordens.
A presença de posições e bandeiras DEAL_ENTRY não deve de forma alguma ser envolvida na lógica.
Só precisamos olhar para o mágico e comentar os novos negócios e ordens atuais como identificadores dos próprios/estrangeiros.
O código de trabalho mostrado. É exatamente a mesma coisa.
Tentar resolver o problema através da OnTradeTransaction é uma má idéia do número de armadilhas. Que em uma determinada tarefa ainda pode, às vezes, ser contornada. Mas se você mudar a tarefa apenas um pouco, toda a lógica é quebrada durante a implementação da OnTradeTransaction-implementação.
Os desenvolvedores criaram um modelo comercial orientado por eventos, mas eles não forneceram um único exemplo de trabalho. Porque é um completo idiota no que o código se derrama e em quanto depende de cada exemplo.
Portanto, eu recomendaria observar as operações comerciais síncronas e a função OnTrade. Lá tudo é muito mais fácil e a lógica é muito flexível para mudanças. Além disso, é mais confiável.
A transição para a Async+Transactions é comparável à transição da linguagem de alto nível para o montador. Isto é, deve ser feito no último estágio da criação da TS, quando ela for COMPLETAMENTE pesquisada, pronta para REAL e a última coisa é acelerar as operações comerciais SEM mudar a lógica comercial.