Características da linguagem mql4, sutilezas e técnicas - página 35

[Andrei Trukhanovich]

fxsaber #:

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.

[fxsaber]

Andrei Trukhanovich #:

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.

[Igor Makanu]

fxsaber #:

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

   int n  = OrdersTotal();
   
   if(n == 0) return(0.0);
   else if(n == 1 && OrderSelect(0, SELECT_BY_POS)) return(OrderLots());
   
   int t_last = OrderSelect(n - 1, SELECT_BY_POS) ? OrderTicket() : -1;
   int t_first = OrderSelect(0, SELECT_BY_POS) ? OrderTicket() : -1;

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().

[fxsaber]

Igor Makanu #:

consegue se lembrar da primeira e última encomenda (bilhete)?

Sem uma memorização completa da seqüência de bilhetes, tal solução falhará.

[Igor Makanu]

fxsaber #:

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?

[fxsaber]

Igor Makanu #:

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.

[Andrei Trukhanovich]

Igor Makanu #:

podemos memorizar a primeira e última encomenda (bilhete)?

lembrando que o primeiro não faz nada

[Taras Slobodyanik]

fxsaber a função ter sido chamada? Ou será contado duas vezes.

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

[Igor Makanu]

Andrei Trukhanovich #:

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

[Valeriy Yastremskiy]

fxsaber #:

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.