Esto es realmente óptimo. Además, permite establecer condiciones de clasificación más complejas.
Por ejemplo:
Sí, y de todos modos no hay otras soluciones.
El objetivo del patrón es ser universal. Si pasas otra estructura en tu ejemplo que no contenga al menos un campo a,b,c, no compilará. Es decir, la función no puede trabajar con dos tipos de datos diferentes al mismo tiempo.
Esta condición funcionará si la orden pendiente se ejecuta parcialmente y genera una posición. Entonces una orden y una posición con el mismo ticket existirán al mismo tiempo.
Por esta razón, la siguiente construcción tiene sentido en algunas situaciones.
Para los que trabajan con transacciones asíncronas, será útil conocer la configuración del número máximo posible de transacciones asíncronas no procesadas en su cuenta.
Esta condición se activará si la orden pendiente se ejecuta parcialmente y genera una posición. Entonces una orden y una posición con el mismo ticker existirán al mismo tiempo.
El siguiente código en una cuenta demode RannForex-Server puede reproducir inmediatamente esta situación ejecutando este EA.
// Воспроизведение ситуации наличия позиции и отложенного ордера с одинаковыми тикетами.#define Ask SymbolInfoDouble(_Symbol, SYMBOL_ASK)
MqlTradeResult Result = {0};
MqlTradeRequest Request = {0};
intOnInit()
{
Request.action = TRADE_ACTION_PENDING;
Request.symbol = _Symbol;
Request.volume = 100;
Request.price = Ask;
Request.type = ORDER_TYPE_BUY_LIMIT;
return(!OrderSend(Request, Result)); // Выставили лимитник по текущей цене.
}
#define TOSTRING(A) #A + " = " + DoubleToString(A, _Digits)
voidOnTradeTransaction( constMqlTradeTransaction&, constMqlTradeRequest&, constMqlTradeResult& )
{
if (OrderSelect(Result.order) && (OrderGetInteger(ORDER_STATE) == ORDER_STATE_PARTIAL)) // Если наш лимитник исполнился частично
{
if (Ask - OrderGetDouble(ORDER_PRICE_OPEN) < 100 * _Point) // и находится близко от текущей цены
{
Request.action = TRADE_ACTION_MODIFY;
Request.order = Result.order;
Request.price = Ask - 1000 * _Point;
// тогда передвигаем его подальше.if (OrderSend(Request, Result)) // Если синхронный OrderSend выполнился успешно, то торговое окружение должно соответствовать.
{
// Проверка соответствия торгового окружения.if (OrderSelect(Request.order) && // Если получилось взять данные нашего ордераNormalizeDouble(OrderGetDouble(ORDER_PRICE_OPEN) - Request.price, _Digits)) // и цена ордера не равна цене успешного OrderSendAlert("Bug:" + TOSTRING(OrderGetDouble(ORDER_PRICE_OPEN)) + " != " + TOSTRING(Request.price)); // сообщаем о баге MT5.
}
}
elseExpertRemove();
}
}
Resultado.
Por cierto, el script muestra (no siempre la primera vez) un error en la ejecución del OrderSend sincrónico.
Después de que OrderSend se ejecute durante unas decenas/centenares de milisegundos, el precio de la orden es el antiguo, y no el que fue colocado con éxito por OrderSend.
Volviendo al tema de los billetes idénticos, podemos sacar algunas conclusiones.
Si se cuelga una orden limitada parcial, la pestaña "Órdenes y operaciones" no mostrará la operación generada.
En una cobertura, una sola orden puede generar múltiples operaciones IN con diferentes precios. El resultado será un precio de apertura fraccionado (en relación con los pips) de la posición.
Puede cerrar la posición generada sin eliminar la venta parcial. Pero si después se activa la orden pendiente, entonces se abrirá una operación con el ticket, igual al ticket de la posición, que se cerró antes. Es decir, puede darse una situación en la que se cierre una posición con una determinada entrada. Y luego vuelve a aparecer una posición con el mismo ticker.
La ejecución parcial puede implementarse de forma diferente, dependiendo del software del corredor. Lo anterior es una implementación estándar de MT5.
Si alguien ha conseguido reproducirlo en otro servidor de comercio, por favor comparta el nombre.
Puede cerrar la posición generada sin borrar la venta parcial. Pero si después se activa la orden pendiente, abrirá una operación con un ticket igual al de la posición cerrada anteriormente. Es decir, puede darse una situación en la que se cierre una posición con una determinada entrada. Y luego vuelve a aparecer un puesto con el mismo billete.
¿No es un billete único? ¿Cómo puede ser esto?
¿Tanto los pedidos como los intercambios tienen entradas únicas?
La explicación es que mientras haya una orden de apertura, siempre hay una posición. Sólo que no siempre es visible: hay un volumen cero. Y este puesto tiene una entrada única. Pues bien, en una cobertura por este motivo es muy posible que haya in-triggers en la misma posición después de las correspondientes operaciones de entrada y salida.
¿Los pedidos y las ofertas tienen incluso billetes únicos?
Son únicos. Pero, por supuesto, ORDER_TICKET puede ser igual a DEAL_TICKET.
Para iniciar sesión y usar el sitio web MQL5.com es necesario permitir el uso de Сookies.
Por favor, active este ajuste en su navegador, de lo contrario, no podrá iniciar sesión.
Ha iniciado sesión. La autenticación de dos factores se ha desactivado. Vuelva a configurarla y escanee un nuevo código QR, o continúe con la autenticación de dos factores desactivada.
Se supone que funciona. Pero no aconsejo hacerlo así).
Esto es realmente óptimo. Además, permite establecer condiciones de clasificación más complejas.
Por ejemplo:
Sí, y de todos modos no hay otras soluciones.
El objetivo del patrón es ser universal. Si pasas otra estructura en tu ejemplo que no contenga al menos un campo a,b,c, no compilará. Es decir, la función no puede trabajar con dos tipos de datos diferentes al mismo tiempo.
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
Panel de control para el comercio. SE NECESITA AYUDA PARA MQL5
Vladimir Karputov, 2020.08.18 09:04
Este código no funcionaría: no se pueden comparar hamburguesas y cuadrados:
Esta condición funcionará si la orden pendiente se ejecuta parcialmente y genera una posición. Entonces una orden y una posición con el mismo ticket existirán al mismo tiempo.
Por esta razón, la siguiente construcción tiene sentido en algunas situaciones.
Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias
Bibliotecas: MT4Orders
fxsaber, 2020.08.20 15:44
Para los que trabajan con transacciones asíncronas, será útil conocer la configuración del número máximo posible de transacciones asíncronas no procesadas en su cuenta.
Esto no es difícil de averiguar.
Ten cuidado, puedes encontrarte con un límite.
Renat dijo hace tiempo que no sólo puedes quedar atrapado en un límite, sino que también puedes quedar bloqueado por un DC
Esta condición se activará si la orden pendiente se ejecuta parcialmente y genera una posición. Entonces una orden y una posición con el mismo ticker existirán al mismo tiempo.
El siguiente código en una cuenta demode RannForex-Server puede reproducir inmediatamente esta situación ejecutando este EA.
Resultado.
Por cierto, el script muestra (no siempre la primera vez) un error en la ejecución del OrderSend sincrónico.
Después de que OrderSend se ejecute durante unas decenas/centenares de milisegundos, el precio de la orden es el antiguo, y no el que fue colocado con éxito por OrderSend.
Volviendo al tema de los billetes idénticos, podemos sacar algunas conclusiones.
Si alguien ha conseguido reproducirlo en otro servidor de comercio, por favor comparta el nombre.
Cadena de búsqueda: Oshibka 010.
¿No es un billete único? ¿Cómo puede ser esto?
¿Tanto los pedidos como los intercambios tienen entradas únicas?
¿No es un billete único? ¿Cómo puede ser eso?
La explicación es que mientras haya una orden de apertura, siempre hay una posición. Sólo que no siempre es visible: hay un volumen cero. Y este puesto tiene una entrada única. Pues bien, en una cobertura por este motivo es muy posible que haya in-triggers en la misma posición después de las correspondientes operaciones de entrada y salida.
¿Los pedidos y las ofertas tienen incluso billetes únicos?
Son únicos. Pero, por supuesto, ORDER_TICKET puede ser igual a DEAL_TICKET.