Organizar el ciclo de pedidos - página 11
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
Sin embargo, es mejor no hacerlo: todo debe estar en su sitio.
En el temporizador EA, tomamos una lista según los criterios requeridos y en list.Total()>xxx hacemos lo que queremos.
Resulta que en el antiguo MQL4, donde no había temporizador, el problema no tenía solución? ¿Por qué molestarse con el temporizador, cuando se puede resolver en unas pocas líneas?
Eso es exactamente lo que estaba mirando.
Y mi puesto
Y, ¿qué sentido tiene en el comercio real que debamos perseguir continuamente el bucle de órdenes? Lo más importante es que es una pérdida de tiempo...
Para tener siempre información actualizada sobre el entorno comercial, y no buscar cada vez que lo necesite, sino consultar las listas disponibles. Y como las listas deben estar siempre actualizadas, merece la pena preocuparse por mantenerlas al día, pero de forma eficiente.
Al fin y al cabo, si no tiene listas, tendrá que buscar la información cuando la necesite. Y no sólo una vez por garrapata. Y ahí es donde aparecerán todos los frenos de cargar repetidamente el entorno.
Aunque aquí también es posible optimizar, si renunciamos a controlar los cambios del entorno y llenamos las listas sólo cuando sea necesario. Pero entonces se perdería la capacidad del EA de reaccionar a las acciones de cierre/modificación/apertura manual del usuario.
Resulta que en el antiguo MQL4, donde no había temporizador, el problema no tenía solución? ¿Por qué molestarse con un temporizador cuando se puede resolver en unas pocas líneas?
Cuando fue imposible hacerlo, tuvimos que pensar cómo resolverlo. Pero ahora es posible ;)
Para tener siempre información actualizada sobre el entorno comercial, y no tener que buscar cada vez que sea necesario, sino remitirse a las listas existentes. Dado que las listas deben estar siempre actualizadas, merece la pena cuidarlas en todo momento, pero de forma eficiente.
Al fin y al cabo, si no tiene listas, tendrá que buscar la información cuando la necesite. Y no sólo una vez por garrapata. Y aquí todas las ralentizaciones aparecerán en la carga repetida del entorno.
Aunque, incluso aquí se puede optimizar - si se niega a controlar los cambios del entorno y llenar las listas sólo cuando sea necesario. Pero entonces, perderá la capacidad de que el EA reaccione a las acciones del usuario en el cierre/modificación/apertura manual.
Esa es la palabra clave"pero eficaz". ¿Y qué sentido tiene actualizar la lista cada milisegundo si la lista sólo puede cambiar cuando llega el siguiente tick? ¿Y por qué no sólo una vez por garrapata? ¿Se puede cerrar una orden fuera de un tic? Tal y como yo lo veo, aunque no haya ningún tick y el EA envíe una orden de abrir/cerrar, es decir, de cambiar el entorno, es decir, la lista, esta acción provocará un tick. O si no lo es, entonces sin una marca causada por otra cosa, la lista no se cambiará. ¿No es así?
Aquí está la palabra clave"pero efectivamente". ¿Y qué sentido tiene actualizar la lista cada milisegundo, si la lista sólo puede cambiar al recibir el siguiente tick? ¿Y por qué no sólo una vez por garrapata? ¿Se puede cerrar una orden fuera de un tic? Tal y como yo lo veo, aunque no haya ningún tick y el EA envíe una orden de abrir/cerrar, es decir, de cambiar el entorno, es decir, la lista, esta acción provocará un tick. O si no lo es, entonces sin una marca causada por otra cosa, la lista no se cambiará. ¿No es así?
En el probador ejecuto OnTimer(), que crea las listas justo desde OnTick(), pero en la vida real no se nota la diferencia...
Pero ahí se necesita un temporizador no sólo para la creación de listas. En definitiva, todo lo que necesitamos a la vez. Por ahora. La elaboración de perfiles adicionales mostrará los cuellos de botella.
Esa es la palabra clave"pero efectivamente". ¿Y cuál es el sentido profundo de actualizar la lista cada milisegundo, si la lista sólo puede modificarse con la llegada de otro tick? ¿Y por qué no sólo una vez por garrapata? ¿Se puede cerrar una orden fuera de un tic? Tal y como yo lo veo, aunque no haya ningún tick y el EA envíe una orden de abrir/cerrar, es decir, de cambiar el entorno, es decir, la lista, esta acción provocará un tick. O si no lo es, entonces sin una marca causada por otra cosa, la lista no se cambiará. ¿No es así?
Hay un punto en la fuerza bruta del temporizador si el programa trabaja con muchos símbolos - los ticks llegan en diferentes momentos.
Pero no tiene sentido buscar "no su" lista de pedidos, sino la creada por el terminal, que es la razón de los problemas de que la lista sea modificada por otra persona.
Hay un punto en la fuerza bruta del temporizador si el programa trabaja con muchos símbolos - los ticks llegan en diferentes momentos.
Pero no tiene sentido buscar "no en su propia" lista de pedidos, sino en la lista creada por el terminal, lo que da problemas cuando la lista es modificada por otra persona.
En el caso de la lista "no propia", hay una cantidad total de pedidos que se puede almacenar en una variable estática y ejecutar el bucle para enumerar el entorno a medida que cambia. Pero no cada milisegundo...
En caso de que la lista sea "no propia" hay un número total de pedidos que se puede almacenar en una variable estática y ejecutar un bucle para volver a ejecutar el entorno a medida que cambia. Pero no cada milisegundo...
No se puede captar la activación de una orden pendiente de esta manera.
No es posible captar la activación de una orden pendiente de esta manera.
Por lo tanto, no estamos hablando de coger pulgas, es decir, una orden pendiente, estamos hablando de probar todas las órdenes cada milisegundo.
Así que no se trata de atrapar pulgas, es decir, órdenes pendientes, sino de revisar todas las órdenes cada milisegundo.
- ¿Para qué necesitas una sartén?
- Por ejemplo, para freír huevos.
- No se trata de huevos revueltos, sino de la sartén...