Bibliotecas: MT4Orders - página 46

 
traveller00:

E, nesse caso, não há como trabalhar com o limitador. Ou existe uma maneira?

Eu fecho as posições definindo um takeout no preço atual. Mas o takeout nem sempre vem na forma de um limite (depende do software da corretora). É por isso que essa solução nem sempre é adequada.

Se for necessário ser exato com um limitador. Eu defino um limitador e, no caso de um hedge, fecho as posições opostas por meio do OrderCloseBy.

 

Presumo que o take seja escolhido para que, no caso de hedging, você possa enviar uma solicitação de take para o servidor em vez de duas solicitações separadas de limit e CloseBy? E para a compensação não faz diferença.

A propósito, pelo que me lembro, na bolsa de valores não era possível colocar um take ou stop loss diretamente no preço atual; deveria haver um recuo.

 
traveller00:

Presumo que o take seja escolhido para que, no caso de hedging, você possa enviar uma solicitação de take para o servidor em vez de dois limit e CloseBy separados? E para a compensação não faz nenhuma diferença.

A operação CloseBy não é uma negociação, portanto, não há muita diferença.

 
É muito fácil encontrar execução parcial no MT5.
// true - transação como resultado de execução parcial.
bool IsPartial( const ulong TicketDeal )
{
  const ulong TicketOrder = HistoryDealGetInteger(TicketDeal, DEAL_ORDER);
  
  return((HistoryDealGetInteger(TicketDeal, DEAL_TYPE) <= DEAL_TYPE_SELL) &&
         (!TicketOrder ||
          (HistoryDealGetDouble(TicketDeal, DEAL_VOLUME) != HistoryOrderGetDouble(TicketOrder, ORDER_VOLUME_INITIAL))));
}


Mostrarei a peculiaridade de usar o estilo MT5 e o estilo MT4 juntos usando essa função como exemplo.

// Saída de todas as transações parcialmente executadas.

#include <MT4Orders.mqh>

input datetime inFrom = D'2020.01.01';

void OnStart()
{
  if (HistorySelect(inFrom, INT_MAX))
  {
    for (int i = HistoryDealsTotal() - 1; i >= 0; i--)
    {
      const ulong TicketDeal = HistoryDealGetTicket(i);
      
      if (IsPartial(TicketDeal))
      {
        Print(TicketDeal);
        
        if (OrderSelect(TicketDeal, SELECT_BY_TICKET) && // Após OrderSelect by ticket, altera a tabela de histórico,
            HistorySelect(inFrom, INT_MAX))              // portanto, ele deve ser retornado, se necessário.
          OrderPrint();        
      }
    }
  }
}

Leve isso em consideração se você trabalhar com HistorySelect+MT4Orders.

 

Há vários locais onde ocorre a seleção da ordem de posição. Com o comentário

// Durante a pesquisa, o número de pedidos pode mudar

é verificado que o número de ordens pode mudar. Mas, a rigor, pode haver uma situação em que o número de ordens não tenha mudado, mas as próprias ordens tenham mudado, como 1 fechada e 1 nova aberta. E então a numeração no meio do caso pode mudar. Essa situação nunca aconteceu durante todo o tempo de uso? A falta de verificações mais rigorosas é um bug ou uma ignorância deliberada de uma situação improvável para não complicar muito o código? Ou eu dei uma olhada em algo e não há nenhum bug aqui?

 
traveller00:

Há vários locais onde ocorre a seleção da ordem de posição. Com comentários

é verificado que o número de ordens pode mudar. Mas, a rigor, pode haver uma situação em que o número de ordens não tenha mudado, mas as próprias ordens tenham mudado, como 1 fechada e 1 nova aberta. E então a numeração no meio do caso pode mudar. Essa situação nunca aconteceu durante todo o tempo de uso? A falta de verificações mais rigorosas é um bug ou uma ignorância deliberada de uma situação improvável para não complicar muito o código? Ou eu dei uma olhada em algo e não há nenhum bug aqui?

Não me lembro. Só sei que fiz muitos testes de estresse para verificar todas as situações.

 

ORDER_TIME_SETUP(_MSC) para o horário de execução da primeira (talvez penúltima) operação. Ou seja, será impossível determinar, a partir do histórico, quando, por exemplo, a BuyLimit foi colocada.


Como consequência, uma posição de hedge pode ter um preço de abertura fracionário, como pode ser observado com frequência na compensação.

Nessa situação, via MT4Orders, OrderOpenPrice/OrderOpenTime dessa posição MT4 será igual aos valores correspondentes da primeira negociação MT5.

Ou seja, infelizmente, não haverá preço fracionário para abrir uma posição. Essa é uma situação rara, mas acontece.

 

Fórum sobre negociação, sistemas de negociação automatizados e teste de estratégias de negociação

Bibliotecas: MT4Orders

fxsaber, 2020.03.18 03:47

Rejeição de empate.

Essa situação pode ocorrer com frequência:

  1. O preço atingiu o takeout de uma posição aberta.
  2. O MT5 gerou uma ordem de mercado. Uma ordem de limite correspondente foi enviada para o provedor de liquidez.
  3. A ordem de limite é registrada novamente. Em seguida, a ordem do MT5 que corresponde à Take é excluída.
  4. Mudar para o ponto 1.
Boa implementação, porque no histórico você pode ver as rejeições dos provedores. Realização interna bem feita e forçada de takeouts como limitadores.

O MT4Orders não mostra essas ordens MT5 em tais situações de um teejk re-jack, bem como nos casos em que a ordem de take foi parcialmente executada e depois cancelada. E é isso mesmo!

 

Última versão MT5 2361 usando MT4Orders, real, hedge. Vários EAs, diferentes magias. Situação de um dos Expert Advisors.

Foi colocada uma ordem de COMPRA, ticket 216684. Depois de algum tempo, era hora de fechar a posição, um limite de VENDA foi colocado para fechá-la e outro limite de VENDA para abrir uma posição inversa, tickets 216975 e 216978. Todas as ordens têm o mesmo tamanho de lote. Quando o limite 216978 foi acionado, o 216684 e o 216978 foram recolhidos via CloseBy e apenas o 216975 permaneceu.

Parte do registro do Journal

2020.04.15 07:33:24.203 : deal #107485  sell 0.15 XXXXXX at 1.05555 done (based on order #216978)
2020.04.15 07:33:24.203 : close position #216684  buy 0.15 XXXXXX by position #216978  sell 0.15 XXXXXX
2020.04.15 07:33:24.305 : accepted close position #216684  buy 0.15 XXXXXX by position #216978
2020.04.15 07:33:24.307 : deal #107487  sell 0.15 XXXXXX at 1.05555 done (based on order #216986)
2020.04.15 07:33:24.307 : close position #216684  buy 0.15 XXXXXX by position #216978  done in 103.841 ms
2020.04.15 07:33:24.309 : deal #107489  sell 0.15 XXXXXX at 1.05563 done (based on order #216975)

Parte do registro do Expert Advisor

2020.04.15 07:33:24.180 OrdersTotal 216978 216975 216684
2020.04.15 07:33:24.305 OrdersTotal

Ou seja, podemos ver que havia 3 ordens. Mas no processo de colapso de duas delas e de mudança para o mercado da terceira, a lista de ordens ficou vazia, embora uma devesse ter permanecido. Essa situação pode levar à abertura dupla de uma posição.

Eu recebo ordens por meio do seguinte código

  int PrevTotal;
  ulong OrderTickets[];
  do
  {
    PrevTotal=OrdersTotal();
    for(int i=PrevTotal-1;i>=0;--i)
    {
      int Total=OrdersTotal();
      if(Total!=PrevTotal)
      {
        PrevTotal=Total;
        i=PrevTotal;
        ArrayFree(OrderTickets);
        continue;
      }
      if(!OrderSelect(i,SELECT_BY_POS,MODE_TRADES) || OrderMagicNumber()!=inTradeMagic)
        continue;

      ArrayResize(OrderTickets,ArraySize(OrderTickets)+1);
      OrderTickets[ArraySize(OrderTickets)-1]=OrderTicket();
    }
  }while(PrevTotal!=OrdersTotal());

E então inseri uma verificação, caso o número mudasse durante a enumeração. Mas ela parece estar faltando. Isso é um bug, um recurso ou entrei em uma área inacabada?

Совершение сделок - Торговые операции - Справка по MetaTrader 5
Совершение сделок - Торговые операции - Справка по MetaTrader 5
  • www.metatrader5.com
Торговая деятельность в платформе связана с формированием и отсылкой рыночных и отложенных ордеров для исполнения брокером, а также с управлением текущими позициями путем их модификации или закрытия. Платформа позволяет удобно просматривать торговую историю на счете, настраивать оповещения о событиях на рынке и многое другое. Открытие позиций...