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
Por isso, agora estou me perguntando como fazer TODAS as encomendas em UM momento.
Não tenho certeza do que fazer, mas estou tentando escrever de tal forma que tais escorregões não levem a conseqüências críticas.
A probabilidade diminuirá, mas menos a diversificação e a complicação da gestão de contas.
Alternativamente, espalhe os bots por diferentes contas.
Em seguida, proibir, por exemplo, a expiração das ordens de put-away. Em geral, uma muleta.
Uma necessidade fundamental com uma peculiaridade tão infeliz. Aparentemente, para fazê-lo através de instantâneos de alguma forma.
Obrigado pela resposta detalhada! Agora eu me pergunto como passar por TODAS as ordens em UM momento.
Que tal lembrar a primeira e última encomenda ( bilhete )?
e após a conclusão do ciclo, verifique se a primeira e última encomenda têm os mesmos bilhetes que antes da contagem
SZY: muito logicamente, OrderSelect() deve ser responsável por esta colisão - deve retornar falso caso a tabela de ordens tenha mudado, mas não me lembro de ter lido em nenhum lugar no fórum que OrderSelect() retornou falso, também não encontrei manipuladores de erros para OrderSelect().
consegue se lembrar da primeira e última encomenda (bilhete)?
Sem uma memorização completa da seqüência de bilhetes, tal solução falhará.
Se você não se lembrar completamente da seqüência de bilhetes, esta solução falhará.
E a economia total de bilhetes também causará falhas porque enquanto passamos por um loop, o estado dos pedidos que já foram processados pode mudar
é claro, não tenho certeza, mas se uma ordem é fechada quando estamos no ciclo, o OrderTotal() irá mudar
se o pedido for fechado e um novo pedido abrir, o bilhete e/ou OrderSelect(0) ou OrderSelect(OrderTotal()-1) será alterado
e em sua opinião, que situação poderia acontecer, de modo que as "ordens extremas" anteriores e a própria OrderTotal() permaneçam?
e em sua opinião, que situação poderia acontecer para manter as mesmas "ordens extremas" e a própria OrderTotal() ?
O mais provável é que o OrderTotal mude quando a tabela de pedidos for abalada.
E então é possível que os limitadores sejam reabastecidos e que uma posição adicional seja criada.
podemos memorizar a primeira e última encomenda (bilhete)?
lembrando que o primeiro não faz nada
Ou seja, o que acontece com a indexação quando um pedido é excluído ou aparece durante a enumeração?
Colecciono uma série de bilhetes e trabalho com ele.
Se as OrdensTotal ou Saldo ou Margem tiverem mudado - então a lista tem que ser recriada.
Assim, a EA sempre trabalha apenas com seus próprios ingressos selecionados
lembrar que o primeiro não faz nada
estas são peculiaridades da implementação da arquitetura, que não estão documentadas e ninguém pode garantir no futuro...
Nota OrderTotal() eOrderHistoryTotal(), e os bilhetes dos últimos pedidos
se esses valores mudarem após os cálculos no loop, então processe
Mas não pode haver uma solução universal e confiável - a tarefa aqui é adivinhar o que vai acontecer no servidor, como os dados são entregues através da rede e o que está acontecendo nos gráficos adjacentes no terminal ))))
A única coisa a se esperar é a velocidade da OrderSelect() - se bem me lembro, é mais de um milhão de chamadas por segundo
Sem uma memória completa da seqüência de emissão de bilhetes, tal solução falhará.
Pode não ser caro lembrar, mas pode ser caro manter um registro completo do status. Concordo com os anteriores, reduzir a carga pela lógica da razoabilidade e das prioridades.
O mundo assíncrono em que vivemos não garante a ordem das respostas à ordem dos pedidos, nem garante ordem em absoluto.