Bibliotecas: MT4Orders - página 63

Nuevo comentario
 
MT4Orders (+ByPass) sólo funciona con HistorySelect(0, INT_MAX), por lo que no crea los problemas actuales de añadir sólo las órdenes borradas al final de la tabla histórica (+sincronización).
 
fxsaber:
MT4Orders (+ByPass) sólo funciona con HistorySelect(0, INT_MAX), por lo que no crea los problemas actuales al añadir sólo las órdenes borradas al final de la tabla del historial (+sync).

¡Roto! No recomiendo actualizar MT5. Quien entienda, que ayude a explicar que el comportamiento anterior de MT5 era correcto. Ahora no lo es.

 
fxsaber:

¡Roto! No recomiendo actualizar MT5. Quien entiende, ayuda a explicar que el comportamiento anterior de MT5 era correcto. Ahora no lo es.

Triste.

He esbozado un código de cómo rastrear la inserción de órdenes en el histórico y actualizarlo en la clase TradesID sólo en periodo "movido" + no más de 100 posiciones en el histórico, es decir, con poca sangre.

NO he probado el código, además de que es, por supuesto, subóptima - sólo una demostración de la idea. (amarillo - lo que se cambia a su original)

//ejemplo de inserción de orden de seguimiento y caché de historial
//!!!does not track deletions or changes to ticket numbers
// en función del ID de operaciones
#include "Classificator.mqh"
class TRADESID
  {
   CLASSIFICATOR<ulong, ulong> OrdersID;
   CLASSIFICATOR<ulong, ulong> DealsID;

   int               LastTotalOrders;
   int               LastTotalDeals;

   //tickets an order at every hundredth position in the history
   ulong             OrderTickets[];


   void              RefreshOrders(void)
     {
      static ulong LastOrderTicket = -1;     //ticket de la orden tomada del pase anterior

      if(::HistorySelect(0, INT_MAX))
        {
         const int Total = ::HistoryOrdersTotal();

         if(this.LastTotalOrders > 0 && LastOrderTicket != ::HistoryOrderGetTicket(this.LastTotalOrders - 1))
           {
            int i;
            //comprueba cada centésima entrada en orden inverso
            for(i = ArraySize(OrderTickets) - 1; i >= 0 && OrderTickets[i] !=::HistoryOrderGetTicket(i * 100) ; i--)
               ;
            if(i < 0)
               LastTotalOrders = 0;
            else
               {LastTotalOrders = i * 100 + 1; LastOrderTicket = OrderTickets[i];}
            ArrayResize(OrderTickets, i + 1);
           }

         while(this.LastTotalOrders < Total)
           {
            const ulong Ticket = LastOrderTicket = ::HistoryOrderGetTicket(this.LastTotalOrders); //(this.LastTotalOrders++)
            
            // por cada centésima posición del historial añade una entrada al array
            if(LastTotalOrders++ % 100 == 0)
               OrderTickets[::ArrayResize(OrderTickets, ::ArraySize(OrderTickets) + 1) - 1] = Ticket;


            const ulong PositionID = ::HistoryOrderGetInteger(Ticket, ORDER_POSITION_ID);

            if(PositionID)
              {
               this.OrdersID.Add(PositionID, Ticket);

               const ulong PositionBy = ::HistoryOrderGetInteger(Ticket, ORDER_POSITION_BY_ID);

               if(PositionBy)
                  this.OrdersID.Add(PositionBy, Ticket);

              }
           }
        } 

      return;
     }
  };

El seguimiento de las eliminaciones/cambios de pedidos es mucho más difícil, pero eso tampoco lo resuelve tu biblia.

Por supuesto, ByPASS y MT4HISTORY necesitan un algoritmo más sofisticado para tal corrección, pero nada complicado, parece (no los he estudiado todavía).

 

También puede realizar el seguimiento de las transacciones TRADE_TRANSACTION_HISTORY_UPDATE y TRADE_TRANSACTION_HISTORY_DELETE como escribió:

https://www.mql5.com/ru/forum/366029/page2#comment_22442705

Si dan el número de ticket, y los pedidos en el historial están ordenados por ticket, entonces la posición del pedido en el historial puede ser fácilmente rastreada a través del array OrderTickets.


P.D. como último recurso, también puedes añadir HashMap...

Библиотеки: TradesID
Библиотеки: TradesID
  • 2021.05.13
  • www.mql5.com
Статьи и техническая библиотека по автоматическому трейдингу: Библиотеки: TradesID
 
mktr8591:

Es triste.

Si no lo devuelven como estaba, podemos hacer una muletilla. Esbocé un código cómo se puede rastrear la inserción de la orden en la historia y actualizarlo en la clase TradesID sólo en el período "desplazado" + no más de 100 posiciones de la historia, es decir, con poca sangre.

NO he probado el código, además es por supuesto subóptimo - sólo una demostración de la idea. (amarillo - lo que se cambia a su original)

Si he entendido bien la idea, usted está buscando el cien en el que se produjo el cambio. Pero yo no entendía cómo el nuevo billete en sí está en ese centenar después. Sobre todo si hay varios y están en diferentes centenas.

El seguimiento de los borrados/cambios de orden es mucho más difícil, pero tu biblia tampoco lo resolvía.

No lo entiendo. ¿Qué es exactamente lo que no se rastrea? Sugiero parar en b2958 por ahora.

Si se trata de editar la historia retroactivamente - no vale la pena. Las soluciones no se crean por frikismo, sino para comerciar.

Por supuesto, ByPASS y MT4HISTORY requieren un algoritmo más sofisticado para tal corrección, pero parece que no es nada complicado (no los he estudiado todavía).

El problema es que cuantas más funciones regulares se llamen en cada pasada, mayor será la probabilidad de lags. El EA empieza a colgarse. Varios Asesores Expertos - aún peor. Cuando hay varios terminales, es bastante malo. Incluso la llegada de OnTradeTransaction se ralentiza - por ejemplo, OrderSend empieza a tardar varias veces más que el ping. Además de que la muletilla implica una depuración salvaje, también creará lags. Imagínese que durante la enumeración se actualiza el historial, etc. Habrá un gran número de bugs.


Después de todo, lo principal es que todo funcionaba perfectamente. Simplemente lo rompieron en un lugar parejo y no lo comentan de ninguna manera.


ZЫ Para mi es un misterio por que casi nadie entiende de que se trata.

 
fxsaber:

ZЫ Es un misterio para mí por qué casi nadie entiende de qué se trata.

Porque nadie ha intentado implementar el trabajo con órdenes en MT5 a) fácilmente, b) correctamente y c) rápidamente. Eso me incluye a mi.

 
fxsaber:

Si he entendido bien la idea, usted busca la centena en la que se ha producido el desplazamiento. Pero no entiendo cómo se sitúa el nuevo Ticket en esta centena. Sobre todo si hay varios y se encuentran en diferentes centenas.


Si sólo hubo inserciones sin eliminaciones, entonces el bucle 

for(i = ArraySize(OrderTickets) - 1; i >= 0 && OrderTickets[i] !=::HistoryOrderGetTicket(i * 100) ; i--)
               ;

busca el principio de la primera centena en la que se produjeron las inserciones. No es necesario buscar la entrada en sí, basta con recorrer todos los pedidos a partir de esta centena y las siguientes (más recientes) y añadirlas al hashmap. Esto se hace como siempre en un bucle while(this.LastTotalOrders < Total). Casi siempre serán 1-2 últimas centenas.

Puede ser mejor reducir el paso - no 100, pero 40 o 20.

En caso de que la historia cambie durante el for - algo se inserta ANTES de la centena encontrada, puede ponerlo en el bucle:

 void              RefreshOrders(void)
     {
      static ulong LastOrderTicket = -1;     //ticket de la orden tomada del pase anterior

      if(::HistorySelect(0, INT_MAX))
        {
         // necesitamos añadir una comprobación para IsStopped y el tiempo máximo de ejecución
         while(this.LastTotalOrders > 0 && LastOrderTicket != ::HistoryOrderGetTicket(this.LastTotalOrders - 1))
           {
            int i;
            //comprueba cada centésima entrada en orden inverso
            for(i = ArraySize(OrderTickets) - 1; i >= 0 && OrderTickets[i] !=::HistoryOrderGetTicket(i * 100) ; i--)
               ;
            if(i < 0)
               LastTotalOrders = 0;
            else
              {LastTotalOrders = i * 100 + 1; LastOrderTicket = OrderTickets[i];}
            ArrayResize(OrderTickets, i + 1);
            ::HistorySelect(0, INT_MAX);
           }

         const int Total = ::HistoryOrdersTotal();

         while(this.LastTotalOrders < Total)
           {
            const ulong Ticket = LastOrderTicket = ::HistoryOrderGetTicket(this.LastTotalOrders);

            // por cada centésima posición del historial añade una entrada al array
            if(LastTotalOrders++ % 100 == 0)
               OrderTickets[::ArrayResize(OrderTickets, ::ArraySize(OrderTickets) + 1) - 1] = Ticket;


            const ulong PositionID = ::HistoryOrderGetInteger(Ticket, ORDER_POSITION_ID);

            if(PositionID)
              {
               this.OrdersID.Add(PositionID, Ticket);

               const ulong PositionBy = ::HistoryOrderGetInteger(Ticket, ORDER_POSITION_BY_ID);

               if(PositionBy)
                  this.OrdersID.Add(PositionBy, Ticket);

              }
           }
        } 
      return;
     }

Pero será muy raro.

 
mktr8591:

Si sólo hay inserciones sin supresiones, entonces el ciclo

busca el principio de la primera centena en la que se produjeron las inserciones. No es necesario buscar la entrada en sí, basta con recorrer todos los pedidos a partir de esta centena y las siguientes (más recientes) y añadirlas al hashmap. Esto se hace como siempre en el bucle while(this.LastTotalOrders < Total). Casi siempre serán 1-2 últimas centenas.

Es decir, ¿uso que añadir repetidamente el mismo ticket al hashmap no cambiará el hashmap?

He tenido órdenes que han llegado a la octava centena. En el comercio activo, este es un fenómeno común con las nuevas construcciones. En este caso, es necesario hashmap varios cientos de órdenes.

 
fxsaber:

Es decir, ¿utilizar que añadir el mismo ticket al hashmap repetidamente no cambiará el hashmap?


Sí, justo ahora me he dado cuenta - si añades un ticket OrdersID.Add(PositionID, Ticket) repetidamente, entonces en OrdersID.ValuesID[] este ticket se invertirá. Es decir, el hashmap se hinchará.

Tenemos que hacer una comprobación de alguna manera. O utilizar HashSet en lugar de una estructura de array para VALUESID. O algo similar.

 
fxsaber:

He tenido órdenes que han llegado al octavo centenar. En el comercio activo, esto es una ocurrencia común con nuevas construcciones. En tal caso, usted debe hashmap varios cientos de órdenes.

Pero no ocurre cada 15 minutos, ¿verdad?
1...565758596061626364656667686970...95
Nuevo comentario