Procesamiento de OnTradeTransaction - página 5

 
fxsaber:

Cretino.

Pensé que te referías a ti.

¿Qué ha pasado con lo de "Ya sedará cuenta si quiere"?"?

 
fxsaber:

Es más fácil para mí responder en un solo post que hacer docenas con "recomendaciones".

Si quiere, lo resolverá.

Solía querer... Pero su código es otra cosa.
 
Alexey Viktorov:
Una vez quise... Pero su código es algo fuera de este mundo.

En este caso sólo se necesita un pequeño conocimiento de MT4/5.

 
fxsaber:

En este caso sólo se necesita un pequeño conocimiento de MT4/5.

Desgraciadamente, sé poco más que un poco.

Ya te lo dije una vez, metes y sacas tu código como un tapón de culo en cada barril. Los que lo necesitan lo usan desde hace mucho tiempo y algunos incluso lo anuncian. Pero imponerlo donde no es muy necesario es simplemente indecente. Sobre todo cuando una persona quiere entender y adentrarse en la programación en mql5, no a través de trucos.

 
Alexey Viktorov:

Desgraciadamente, sé poco más que un poco.

Ya te lo he dicho una vez, metes tu código en todos los barriles para hacer negocio y sin razón alguna. Los que lo necesitan lo usan desde hace mucho tiempo y algunos incluso lo anuncian. Pero imponerlo donde no es muy necesario es simplemente indecente. Sobre todo cuando una persona quiere entender y adentrarse en la programación en mql5, no a través de trucos.

Verás, cuando haces algunas afirmaciones, es una buena idea respaldarlas de alguna manera en la práctica. En algunas páginas no ha aparecido ninguna solución OnTradeTransaction. Y si lo hay, se aclarará rápidamente por qué la solución dada es como es y no al revés. La solución debe mostrar la lógica, no el infierno fuera de ella. Si elimino el complemento, el código fuente no perderá ni un ápice de su lógica. Y sólo hay que entender la lógica (idea), nada más.

Estoy de acuerdo con esta afirmación. Una vez que se entiende la lógica, se desechan todos los includes y se crean los propios. Esto es exactamente lo que se propone: dominar no un inlude, sino mostrar mediante código y no asustar cómo puede funcionar la tarea cuya solución se requiere.

 

Aquí vuelvo al origen del problema. Y surgen las preguntas:

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

Procesamiento de OnTradeTransaction

Ilya Child, 2019.02.07 20:08

Buenas noches.

Chicos, por favor, ayuden a resolver esto. El problema probablemente no es nuevo, pero no he encontrado ninguna solución inequívoca (ni en la práctica, ni en los foros).

Estoy ejecutando 2 robots diferentes en el terminal en 2 instrumentos diferentes. Las magias son diferentes en todas partes. El robot coloca límites pendientes y el procedimiento OnTradeTransaction me permite detectar una transacción y colocar órdenes stop pendientes utilizando esta transacción.

A continuación se muestra el código de la transacción comercial

case TRADE_TRANSACTION_DEAL_ADD:
        {
         drop_info2("TRADE_TRANSACTION_DEAL_ADD\r\n"+TransactionDescription(trans));
         if((trans.deal_type==DEAL_TYPE_BUY || trans.deal_type==DEAL_TYPE_SELL) && trans.order!=0)
           {
            if(getIsDealOfExpert(trans.deal)) //функция проверки принадлежности сделки к роботу
              {
               drop_info2("Сделка наша");
               analyzeFilledOrder(trans.order,trans.volume); //процедура по выставлению отложенных стоп ордеров
              }
           }
        }
      break;

Este es el código de la función que comprueba si el acuerdo pertenece a un robot

bool getIsDealOfExpert(ulong dealTicket)
     {
      if(HistoryDealSelect(dealTicket) && HistoryDealGetInteger(dealTicket,DEAL_MAGIC)==magic_number && HistoryDealGetString(dealTicket,DEAL_SYMBOL)==symbol)
         return true;
      else
         return false;
     }

Este es el código del procedimiento para las órdenes de stop pendientes

void analyzeFilledOrder(ulong orderTicket,double volume)
  {
   bool isFindOrder=false;
   string fullComment;
   ENUM_ORDER_TYPE orderType;
   if(getIsOrderOfExpert(orderTicket,true)) //Если ордер из сделки уже в истории
     {
      fullComment=HistoryOrderGetString(orderTicket,ORDER_COMMENT);
      orderType=ENUM_ORDER_TYPE(HistoryOrderGetInteger(orderTicket,ORDER_TYPE));
      isFindOrder=true; //локальная переменная, если нашли в истории
     }
   if(!isFindOrder && getIsOrderOfExpert(orderTicket,false)) //Если не нашли ордер в истории и ордер есть не в истории
     {
      fullComment=OrderGetString(ORDER_COMMENT); 
      orderType=ENUM_ORDER_TYPE(OrderGetInteger(ORDER_TYPE));
      isFindOrder=true; //локальная переменная, если нашли не в истории
     }
   if(isFindOrder) //если хоть где-то нашли, то выставляем отложенные стоп ордера
     {
     //выставляем стоп ордера

Este es el código de la función para buscar un pedido en el historial y fuera del historial

bool getIsOrderOfExpert(ulong OrderTicket,bool isHistory)
     {
      bool is_expert=false;
      //если ордер находится в истории
      if(isHistory)
        {
         if(HistoryOrderSelect(OrderTicket) && HistoryOrderGetInteger(OrderTicket,ORDER_MAGIC)==magic_number && HistoryOrderGetString(OrderTicket,ORDER_SYMBOL)==symbol)
            is_expert=true;
        }
      else
        {
         if(OrderSelect(OrderTicket) && OrderGetInteger(ORDER_MAGIC)==magic_number && OrderGetString(ORDER_SYMBOL)==symbol)
            is_expert=true;
        }
      return is_expert;
     }

La información sobre las transacciones entrantes se publicaría en los archivos de registro en el orden en que se reciben en el terminal. Ahora tengo un problema que he enfrentado al operar en una cuenta demo:

A veces las transacciones vienen en el siguiente orden TRADE_TRANSACTION_ORDER_DELETE, luego TRADE_TRANSACTION_DEAL_ADD, luego TRADE_TRANSACTION_HISTORY_ADD. En este caso, las órdenes de stop no suelen colocarse tras la ejecución de una operación. Supongo que esto ocurre porque el pedido ya ha sido eliminado pero aún no se ha añadido al historial. Significa que no podemos encontrar la orden del acuerdo ni en el historial ni en el terminal. Aunque es dudoso, el hecho es que no se coloca ninguna orden de stop porque el robot no la encuentra después de buscar la orden en todas las dimensiones(isFindOrder=false). En todos los casos, el robot detecta la transacción correctamente, pero no llega a colocar las órdenes.Sin embargo, en ocasiones también funciona correctamente y se colocan las órdenes.

He probado diferentes enfoques, nada funciona. Ahora estoy pensando en añadir un intervalo de 1 segundo al principio del procedimiento de colocación de pedidos pendientes. No sé dónde más cavar.

Por favor, comparta sus experiencias e ideas.

¿Cómo puedo conciliar lo destacado con la siguiente frase?

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

Procesamiento de OnTradeTransaction

Ilya Child, 2019.02.07 20:20

Se me olvidó añadir que el modo es de red. La posición es la misma para todos los robots. Es decir, un robot compró una posición, el segundo la compró, los eventos TRADE_TRANSACTION_DEAL_ADD llegaron en orden inverso y finalmente el primer robot no lo vio.

Sí y lógicamente necesito que me comenten la orden del comercio, la posición no es de mucha ayuda aquí.

No prestemos atención a la errata, uno compró el otro compró... Lo principal es que parece que dos EAs trabajan en un símbolo con el tipo de cuenta de red... ¿O tal vez no entiendo algo?

 
Alexey Viktorov:

No prestemos atención a la errata, uno compró el otro compró... Lo principal es que parece que dos EAs están trabajando en el mismo instrumento con el tipo de cuenta de compensación... ¿O tal vez no entiendo algo?

Es normal tener varios EAs en un símbolo de red. Por ejemplo, las de red. Así que es muy posible que la posición neta sea cero, pero hay dos SL y dos TP. El problema está claramente formulado arriba.

 
fxsaber:

Lo normal es que haya varios EA en un mismo símbolo de red. Por ejemplo, los asesores de redes. Así que es muy posible que la posición neta sea cero, pero que haya dos SL y dos TP. El problema está claramente formulado arriba.

Podemos adivinar lo que queramos. Me gustaría escuchar al "Jefe de Transporte". Al fin y al cabo, he citado sus posts.

 
Alexey Viktorov:

Podemos inventar todo lo que queramos. Me gustaría escuchar al director de transporte. Le estaba citando.

Creo que el jefe se ha visto tan "intimidado" que no volverá a aparecer :)

 
Илья Ребенок:

No te sigo del todo. Este es mi procesamiento de transacciones

Sobre el estado de la orden en la transacción. Te das cuenta de que no me lo estoy inventando. En todas las transacciones deal_add este es el estado del pedido. Tenga en cuenta que es una orden de mercado y que antes era una orden pendiente.

Ahora tenemos otra parte de incomprensión. Una transacción deal_add voló y la posición no apareció y se colocó el pendiente en la posición inexistente.

Añadido.

La transacción Deal_add se envía, pero la posición no se ha colocado y se ha colocado una orden pendiente para la posición no existente. El tipo de operación es Venta, el tipo de orden es Compra. Aunque inicialmente el límite era Sell_limit

Al parecer, o bien la información antigua no se borra en algún lugar, o se toma la información no inicializada.

Si tengo un deal_add, el pedido suele estar ya en el historial, o ya ha sido eliminado, pero aún no ha aparecido en el historial.

Aunque también ocurre que el pedido sigue ahí, y entonces está en el estado colocado.

Pero difícilmente puede ser en este momento.

Comprueba cuando se selecciona una orden o una historia que _están_ realmente seleccionadas.

Razón de la queja: