![MQL5 - Lenguaje de estrategias comerciales para el terminal de cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Así que ahora me pregunto cómo revisar TODOS los pedidos de una sola vez.
No estoy seguro de lo que hay que hacer, pero estoy tratando de escribirlo de tal manera que esos deslices no lleven a consecuencias críticas.
La probabilidad disminuirá, pero sin la diversificación y la complicación de la gestión de cuentas.
Otra opción es repartir los bots entre diferentes cuentas.
Entonces prohíbe, por ejemplo, el vencimiento de las órdenes de retirada. En general, una muleta.
Una necesidad fundamental con una peculiaridad tan desafortunada. Al parecer, hacerlo a través de instantáneas de alguna manera.
Gracias por la detallada respuesta. Ahora me pregunto cómo revisar TODOS los pedidos de una sola vez.
¿Qué tal si recordamos el primer y el último pedido ( ticket )?
y una vez completado el ciclo, compruebe que el primer y el último pedido tienen los mismos tickets que antes del recuento
SZY: lógicamente, OrderSelect() debería ser responsable de esta colisión - debería devolver false en caso de que la tabla de pedidos haya cambiado, pero no recuerdo haber leído en ningún lugar del foro que OrderSelect() haya devuelto false, tampoco he encontrado manejadores de error para OrderSelect().
¿puede recordar el primer y el último pedido (billete)?
Sin una memorización completa de la secuencia de billetes, esta solución fracasará.
Si no recuerdas completamente la secuencia de entradas, esta solución fallará.
Y el guardado completo de los tickets también provocará fallos porque mientras estamos ejecutando un bucle, el estado de los pedidos que ya han sido procesados puede cambiar
por supuesto, no estoy seguro, pero si se cierra un pedido cuando estamos en el ciclo, el OrderTotal() cambiará
si la orden se cierra y se abre una nueva orden, se cambiará el ticket y/o OrderSelect(0) o OrderSelect(OrderTotal()-1)
y, en su opinión, ¿qué situación podría darse para que las anteriores "órdenes extremas" y el propio OrderTotal() permanezcan?
y en su opinión, ¿qué situación podría darse para mantener las mismas "órdenes extremas" y el propio OrderTotal()?
Lo más probable es que el OrdersTotal cambie cuando se agite la tabla de pedidos.
Y entonces es posible que los limitadores se rellenen y se cree una posición adicional.
¿podemos memorizar el primer y el último orden (billete)?
recordando la primera no hace nada
Es decir, ¿qué ocurre con la indexación cuando se elimina un pedido o aparece durante la enumeración?
Recojo una serie de billetes y trabajo con ellos.
Si el Total de Pedidos o el Saldo o el Margen han cambiado - entonces la lista tiene que ser recreada.
Así que EA siempre trabaja sólo con sus propias entradas seleccionadas
recordando que el primero no hace nada
son peculiaridades de la implementación de la arquitectura, que no están documentadas y nadie puede garantizar en el futuro...
Observe OrderTotal() yOrdersHistoryTotal(), y los tickets de los últimos pedidos
si estos valores cambian después de los cálculos en el bucle, entonces procesa
Pero no puede haber una solución universal y fiable: la tarea consiste en adivinar qué ocurrirá en el servidor, cómo se entregan los datos a través de la red y qué ocurre en los gráficos adyacentes en el terminal ))))
Lo único que hay que esperar es la velocidad de OrderSelect() - si no recuerdo mal, es más de un millón de llamadas por segundo
Sin una memoria completa de la secuencia de emisión de billetes, esta solución fracasará.
Puede que no sea costoso recordarlo, pero puede serlo seguir el estado completo. Estoy de acuerdo con los anteriores, reducir la carga por lógica de lo razonable y las prioridades.
El mundo asíncrono en el que vivimos no garantiza el orden de las respuestas al orden de las peticiones, ni garantiza el orden en absoluto.