Cómo comprobar si una orden está seleccionada - página 4
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
De hecho, hay mucha demagogia.
Todo lo que necesitamos para saber si una orden está seleccionada o no.
Lo he explicado al principio del tema, ¿no está claro?
Tenemos alguna función que potencialmente maneja las órdenes, es decir, las selecciona y analiza. Puede ser llamado desde diferentes fragmentos de código, incluyendo aquellos que ya tienen una orden seleccionada para trabajar. Si esta función separada no guarda la orden ya seleccionada y restablece su selección, se producirán errores en la lógica del EA, ya que cuando volvamos de esta función, la orden seleccionada antes de ser llamada será errónea. Por lo tanto, para evitar estos errores, necesitamos recordar la orden actualmente seleccionada desde el lugar de su llamada en cada función auxiliar que maneja órdenes por sí misma y devolver su selección cuando haya terminado. Cómo llevar a cabo esta tarea fácilmente y sin generar errores - esta es la cuestión del tema actual
// Implica que una orden es seleccionada a través de OrderSelect (o hay un error).
¿Por qué un error? Si la orden no se elige, esta acción simplemente no es necesaria, pero parece que es imposible averiguar de antemano si la orden se elige o no sin trucos especiales
// Entonces, ¿por qué debería ser seleccionado de nuevo?
Por eso, después de volver de esta función a la parte del código que la llama, la orden seleccionada en esta parte del código antes de la llamada de la función permanece seleccionada - para que las operaciones que se realizan con la orden actualmente seleccionada no den lugar a errores
No, está realmente en el tanque.
Lo he explicado todo al principio del hilo, ¿tan poco claro está?
Tenemos alguna función que potencialmente trabaja con órdenes, es decir, las selecciona y las analiza. Se puede llamar desde diferentes fragmentos de código, incluyendo aquellos que ya tienen una orden seleccionada para trabajar. Si esta función separada no guarda la orden ya seleccionada y restablece su selección, se producirán errores en la lógica del EA, ya que cuando volvamos de esta función, la orden seleccionada antes de ser llamada será errónea. Por lo tanto, para evitar estos errores, necesitamos recordar la orden actualmente seleccionada desde el lugar de su llamada en cada función auxiliar que maneja órdenes por sí misma y devolver su selección cuando haya terminado. Cómo realizar esta tarea fácilmente y sin generar errores es la cuestión de este mismo tema
1. Para pasar a la función el número de la orden seleccionada antes de ser llamada.
2. Cuando la función termine, vuelva a seleccionar la misma orden.
¿Cómo sé lo que quieres conseguir? Tendrás que ser más específico :(
1. Envía el número de la orden seleccionada antes de llamar a la función.
2. Cuando la función termine, vuelva a seleccionar el mismo orden.
¿Cómo sé lo que quieres conseguir? Deberías ser más claro :(
Sí, lo entiendo, sin embargo, me gustaría escribir funciones informativas, como el beneficio total o las órdenes abiertas, que puedan ser llamadas sin pensar que van a cambiar algo en la lógica de ejecución del programa. Esto es bastante lógico, creo.
No siempre es trivial pasar la orden seleccionada en la función de llamada, imaginemos que el anidamiento de llamadas >1, ¿debemos pasar un ticket a cada función para que alguna función de información menor pueda utilizarlo?
Sería más lógico dar un wrapper a OrderSelect y OrderTicket, que almacenara y obtuviera información sobre el pedido actualmente seleccionado desde una variable separada, pero aquí terminamos con la duplicación de información (la terminal ya sabe si el pedido está elegido, pero no puede pasar esta información sin un potencial error). Así que, o bien obtenemos una duplicación de información o una complicación excesiva de las funciones (también pasamos la orden seleccionada desde el principio a cada parámetro), o una generación forzada de errores de ejecución del programa.
Sí, lo entiendo, pero me gustaría escribir funciones informativas, como el beneficio total o el número de órdenes abiertas, que puedan ser llamadas sin pensar que van a cambiar la lógica de ejecución del programa. Esto tiene sentido, creo.
Tiene sentido, pero en este caso deberíamos al menos dividir las funciones en "blancas" y "negras". El número de orden seleccionado en el primero se guarda, y cuando se viola en el segundo, se restablece.
Parece ser tan simple como eso.
Sí, lo entiendo, pero me gustaría escribir funciones informativas, como el beneficio total o el número de órdenes abiertas, que puedan ser llamadas sin pensar que van a cambiar la lógica de ejecución del programa. Esto es bastante lógico, creo.
No siempre es trivial pasar una orden seleccionada en una función de llamada, imagina que el anidamiento de llamadas es >1, ¿no debería pasarse un ticket a cada función para que alguna función de información menor pudiera utilizarlo?
Mira la biblioteca de funciones de Kim y verás que cada función enumera, selecciona y comprueba el billete, y luego lo que necesitas saber. Tu "lógica" no te permite aprender las reglas básicas de la programación.
Tienes un anciano en un campo, y un tío en Kiev.
Mire la biblioteca de funciones de Kim y vea que cada función hace la enumeración, la selección y la comprobación del billete, y luego lo que hay que aprender. Su "lógica" no le permite aprender las reglas alfabéticas de la programación.
Un pequeño anciano en un jardín y un tío en Kiev.
Boris, no es necesario. Me refiero al ABC.