Cómo comprobar si una orden está seleccionada - página 19
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
En principio, sí, pero el "puntero" tendrá que tener su propio puntero. piensa en mi propuesta con la función, me parece una solución universal. por supuesto hay una cuestión sobre la velocidad de tal código, pero parece ser la tercera cuestión.
Gracias, siempre estoy contento de tener una conversación constructiva.
Así, si la función A del programa selecciona algún orden en el bucle y luego llama a la función auxiliar B de la biblioteca, aunque B seleccione otro orden en el proceso, la selección de orden en la función A no debería verse afectada por el retorno.
Gracias, siempre es un placer mantener una conversación constructiva.
De nada, pero no saques conclusiones precipitadas.
Si almacena el valor de la función en una variable, sí. Si no, la función es global y puede cambiar en la primera llamada.
Estoy un poco confundido. Me refería a la siguiente situación: llamamos a la función de biblioteca B() desde la función A() en el módulo del programa principal, que, por ejemplo, simplemente selecciona el primer orden de la lista (suponiendo que haya un orden a priori):
void B(){
OrderSelect(0,SELECT_BY_POS);
}
Cuando el control vuelve de la librería al módulo principal después de llamar a esta función, si llamamos a OrderTicket() o a cualquier otra función de la misma que espere que el pedido esté preseleccionado, obtendremos exactamente el mismo error 4105. Pero si antes de la llamada de la función B en el módulo principal ya se ha seleccionado alguna otra orden, ésta seguirá seleccionada independientemente del nuevo Select en la biblioteca, porque la orden actualmente seleccionada, según tengo entendido, es única sólo dentro del módulo.
Pero si llamamos a la misma función B desde la función A del módulo principal, entonces el orden seleccionado en la función A antes de la llamada a B cambiará al orden 0 (es decir, el orden actualmente seleccionado después de regresar de la función B será el orden 0, sin importar cuál era el orden actualmente seleccionado antes de la llamada a B).
Por lo tanto, si llamamos a una función que utiliza OrderSelect por sí misma, debemos asegurarnos de que cuando volvemos de esta función el orden que hemos elegido antes de llamar a esta función, para que podamos utilizarlo más tarde. Si no te aseguras de ello, puede llevar a errores lógicos difíciles de encontrar en tu código.
En concreto, el "puntero" -el estado de la selección de orden actual- es global dentro del módulo, es decir, este puntero es el mismo para la biblioteca y diferente para el módulo del programa. Esto significa que si la función A en el programa selecciona algún orden en el bucle y luego llama a la función auxiliar B de la biblioteca, entonces incluso si durante su operación B selecciona otro orden, la selección de orden en la función A no debe ser cambiada al regreso. Pero si ambas funciones están dentro de un módulo, entonces al regresar de la función B, necesitamos recordar y restaurar la selección de orden actual, ya sea antes y después de que B sea llamada en la propia función A o en la función B cuando comience y termine su trabajo para que la lógica del trabajo de la función A no sea violada en ese punto.
Su punto es claro...
Veo una analogía con las construcciones populares de los Asesores Expertos cuando los números de los tickets se almacenan en variables y se utilizan más tarde (en los próximos ticks, como si se ha abierto un byticket, etc.)...
Si quiere obtener un ticket del último pedido abierto, sólo tiene que utilizar las propiedades de este pedido, OrderSelect() y todo irá bien.Significa que en cualquier momento, el Asesor Experto tiene que "entender" en qué estado se encuentra la estrategia de negociación y actuar de acuerdo a este estado, sin importar lo que ocurra con la electricidad y otros Asesores Expertos en funcionamiento en el terminal.
Cuando el control vuelve de la librería al módulo principal después de haber llamado a esta función, si llamamos a la función OrderTicket() o a cualquier otra función de la misma que haya sido diseñada para que el pedido sea preseleccionado, obtendremos exactamente el mismo error 4105. Pero si antes de llamar a la función B en el módulo principal ya se ha seleccionado alguna otra orden, ésta seguirá seleccionada independientemente del nuevo Select en la biblioteca, porque la orden actualmente seleccionada, según tengo entendido, es única sólo dentro del módulo.
¿se ha demostrado que funciona así, o crees que funciona así?
Para mí no hay separación en módulos y bibliotecas... una vez compilado el código funciona como una sola construcción...
siempre que se llame a OrderSelect() se devolverá el mismo OrderTicket() del último pedido seleccionado...
Creo que debería funcionar así...
está demostrado que funciona así, ¿o crees que lo hace?
Para mí no hay división en módulos y bibliotecas... después de la compilación el código funciona como una sola construcción...
Siempre que se llame a OrderSelect() se devolverá el mismo OrderTicket() del último pedido seleccionado...
Creo que debería funcionar así...
Se ha comprobado que el orden seleccionado en la biblioteca no es el orden seleccionado cuando se devuelve en el módulo principal. Por lo tanto, la orden que se selecciona lógicamente debería ser la última orden seleccionada en el módulo principal, aunque todavía no lo he comprobado.
Yo mismo resolví este problema creando envoltorios para las funciones de la biblioteca en el archivo de inclusión de la biblioteca mqh similar al siguiente:
bool GetOrder(int a=0){
return(OrderSelect(_GetOrder(a),SELECT_BY_TICKET));
}
Por cierto, tampoco se pueden pasar parámetros por defecto a las funciones de la biblioteca.
Aquí _GetOrder(int a) es la propia función de la biblioteca que encuentra y devuelve algún orden. La función se llama desde la biblioteca con un parámetro explícito "a", en la función envolvente es 0 por defecto, además el ticket devuelto en la envoltura se selecciona de nuevo en el módulo del programa principal, porque su selección en la función de la biblioteca no llegará al "destinatario".
Yo también lo creo, no importa desde donde se llame a esta función, dará un conjunto de parámetros seleccionados para un orden determinado y el programa no los cambiará hasta la siguiente llamada a esta función, no importa desde donde venga esa llamada.
¿Por qué, si no, envolvería esta función en una función adicional completamente innecesaria?
PYSYS. Consejo - crear una variable entera estática, pasar el valor de la orden después de la apertura, no va a cambiar, hasta que usted quiere, y llevará a cabo con precisión lo que usted ha planeado.
Comprobado que el orden seleccionado en la biblioteca no es el orden seleccionado al volver al módulo principal. Así que, lógicamente, la orden seleccionada en la devolución debería ser la última orden seleccionada en el módulo principal, aunque todavía no lo he comprobado.
Esta afirmación necesita ser aclarada: La afirmación es verdadera si estamos hablando de un módulo (biblioteca) que se compila SOLO (*.mg4-libraries de la carpeta de bibliotecas). Para los módulos que forman parte del archivo compilado principal (*.mgh-library), esta afirmación NO es cierta.
MQH no es un módulo independiente, sino una inserción en el módulo principal, situada en un archivo diferente. Así que, por supuesto, estamos hablando de una biblioteca .ex4 separada