Bibliotecas: MT4Orders - página 46

 

¿Supongo que la toma se elige para que para la cobertura pueda enviar 1 solicitud de toma al servidor en lugar de 2 separadas límite y CloseBy? Y para netting no hay diferencia.

Por cierto, que yo recuerde, en bolsa no se podía poner un take o stop loss directamente en el precio actual, debía haber una sangría.

 
traveller00:

Supongo que la toma se elige de modo que para la cobertura se puede enviar 1 solicitud de toma al servidor en lugar de 2 separadas límite y CloseBy? Y para netting no hace ninguna diferencia.

La operación CloseBy no es una operación, así que no hay mucha diferencia.

 
Es muy fácil encontrar ejecuciones parciales en MT5.
// true - transacción como resultado de una ejecución 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))));
}


Voy a mostrar la peculiaridad de utilizar MT5-estilo y MT4-estilo juntos utilizando esta función como un ejemplo.

// Salida de todas las transacciones parcialmente ejecutadas.

#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) && // Después de OrderSelect por ticket, cambia la tabla de historial,
            HistorySelect(inFrom, INT_MAX))              // por lo que debe ser devuelto si es necesario.
          OrderPrint();        
      }
    }
  }
}

Tenlo en cuenta si trabajas con HistorySelect+MT4Orders.

 

Hay varios lugares en los que se produce la selección del orden de posición. Con el comentario

// Durante la búsqueda el número de pedidos puede cambiar

se comprueba que el número de órdenes puede cambiar. Pero, estrictamente hablando, puede haber una situación en la que el número de órdenes no ha cambiado, pero las propias órdenes han cambiado, como 1 cerrada y 1 nueva abierta. Y entonces la numeración en el medio del caso puede cambiar. Tal situación nunca ha ocurrido durante todo el tiempo de uso? ¿Es la falta de comprobaciones más estrictas un error o una ignorancia deliberada de una situación improbable para no complicar demasiado el código? ¿O me he fijado en algo y aquí no hay ningún bug?

 
traveller00:

Hay varios lugares donde se produce la selección del orden de posición. Con el comentario

se comprueba que el número de órdenes puede cambiar. Pero, estrictamente hablando, puede haber una situación en la que el número de órdenes no ha cambiado, pero las propias órdenes han cambiado, como 1 cerrada y 1 nueva abierta. Y entonces la numeración en el medio del caso puede cambiar. Tal situación nunca ha ocurrido durante todo el tiempo de uso? ¿Es la falta de comprobaciones más estrictas un error o una ignorancia deliberada de una situación improbable para no complicar demasiado el código? ¿O me he fijado en algo y aquí no hay ningún bug?

No me acuerdo. Sólo sé que hice muchas pruebas de estrés para comprobar todas las situaciones.

 

ORDER_TIME_SETUP(_MSC) por la hora de ejecución de la primera (quizás penúltima) operación. Es decir, será imposible determinar a partir del historial cuándo, por ejemplo, se colocó BuyLimit.


Como consecuencia, una posición de cobertura puede tener un precio de apertura fraccionario, como puede observarse a menudo en la compensación.

En esta situación, a través de MT4Orders OrderOpenPrice/OrderOpenTime de dicha posición MT4 será igual a los valores correspondientes de la primera operación MT5.

Es decir, no habrá precio fraccionario para la apertura de una posición, por desgracia. Esta es una situación rara, pero sucede.

 

Foro sobre trading, sistemas automatizados de trading y testeo de estrategias de trading

Bibliotecas: MT4Orders

fxsaber, 2020.03.18 03:47

Rechazo de empate.

Esta situación puede ocurrir a menudo:

  1. El precio ha alcanzado la toma de una posición abierta.
  2. MT5 generó una orden de mercado. Una orden límite correspondiente fue enviada al proveedor de liquidez.
  3. La orden Límite se vuelve a registrar. Entonces se borra la orden MT5 que corresponde a la Toma.
  4. Cambio al punto 1.
Buena implementación, porque en el historial se pueden ver los rechazos de los proveedores. Bien y forzada la realización interna de takeouts como limitadores.

MT4Orders no muestra estas ordenes MT5 en tales situaciones de un teejack re-jack, así como en los casos en que una orden take fue parcialmente ejecutada y luego cancelada. ¡Y así es!

 

Última versión MT5 2361 utilizando MT4Orders, real, de cobertura. Varios EAs, diferentes magos. Situación de uno de los Asesores Expertos.

Se colocó una orden de COMPRA, ticket 216684. Pasado un tiempo llegó el momento de cerrar la posición, se colocó una de VENTA para cerrarla y otra de VENTA para abrir una posición inversa, tickets 216975 y 216978. Todas las órdenes son del mismo tamaño de lote. Cuando el límite 216978 se activó, 216684 y 216978 se colapsaron mediante CloseBy y sólo quedó 216975.

Parte del registro del Diario

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 del registro del Asesor Experto

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

Es decir, podemos ver que había 3 órdenes. Pero en el proceso de colapsar 2 de ellas y moverse al mercado de la 3ª, la lista de órdenes estaba vacía, aunque 1 debería haber permanecido. Esta situación puede provocar la doble apertura de una posición.

Obtengo las órdenes a través del siguiente 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());

Y por eso inserté una comprobación, por si el número cambiaba durante la enumeración. Pero parece que falta. ¿Es esto un error, una característica o me he metido en un área inacabada?

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

Es un error de MT5.

¿La orden entra en el historial? Falta claramente HistoryOrdersTotal además de PositionsTotal, OrdersTotal. Si cambia y se ejecutó la última orden, entonces hay que esperar a que cambie la posición. En cualquier caso, la cuestión es que hay que tener una copia del entorno y comprobar con ella, ateniéndose a la regla de que si en algún sitio hay una pérdida/llegada, entonces en otro sitio llegará/desaparecerá al contrario.