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
La necesidad de esta funcionalidad aumentará a medida que aumente el número de tipos de objetos. Y será necesario cuando cree objetos en los que no pueda determinar el número de puntos de anclaje por su tipo. Por ejemplo, puede ser una polilínea de algún tipo. Pero por ahora no es muy crítico, pero puede ser ejecutado como un deseo en el servicio de escritorio.
Por ahora, es más realista (si es que existe tal necesidad) crear una función de conmutación que dé el número de puntos de anclaje por tipo de objeto.
Solo hay que hacer esta tabla (MQL5 Reference / Standard constants, enumerations and structures / Object constants / Object types) en switch. El parámetro de entrada de la función será ObjectGetInteger(chart_id,name,OBJPROP_TYPE).
No hay peligros ocultos, ya que todos los tipos están rígidamente ligados a los puntos de anclaje. Pero si los objetos con un número variable de puntos aparecen, entonces habrá una necesidad imperiosa de tal funcionalidad.
Ahora, la forma más realista (si lo necesitas) es crear una función de conmutación que dé el número de puntos de anclaje en función del tipo de objeto.
Hace tiempo que pedí una propiedad en ObjectGet.
me parece que esto tiene que ver con la propia lógica en las entrañas de MT5.
Probablemente, sólo revisa todos los puntos y comprueba si están vacíos. Y si un punto tiene un dígito normal, se acumula.
Por tanto, no existe una relación directa entre el tipo de objeto y el número de puntos de anclaje.
Por eso has señalado correctamente que tienes que hacer el cambio tú mismo.
Ahora, la forma más realista (si lo necesitas) es crear una función de conmutación que dé el número de puntos de anclaje en función del tipo de objeto.
Solo hay que hacer esta tabla (MQL5 Reference / Standard constants, enumerations and structures / Object constants / Object types) en switch. El parámetro de entrada de la función será ObjectGetInteger(chart_id,name,OBJPROP_TYPE).
No hay peligros ocultos, ya que todos los tipos están rígidamente ligados a los puntos de anclaje. Pero si obtenemos nuevos objetos con un número variable de puntos, realmente necesitaremos esta funcionalidad.
Hace tiempo que pedí una propiedad en ObjectGet.
Si hay objetos con un número variable de puntos, esta funcionalidad será muy necesaria.
Probablemente, sólo revisa todos los puntos y comprueba si están vacíos. Y si un punto tiene un dígito normal en él, se acumula.
Por tanto, no existe una relación directa entre el tipo de objeto y el número de puntos de anclaje.
Si hay un número variable de puntos, entonces habrá una necesidad extrema de dicha funcionalidad.
Sí, como he escrito más arriba, lo tengo implementado a través de un interruptor. Funciona sin problemas. Pero la idea va más allá, quiero más comodidad y universalidad.
Por cierto, creo que sería bueno permitir a los usuarios crear sus propios objetos. Por ejemplo, al menos permitir fusionar objetos estándar en grupos con una "marca" común. Para que sea posible referirse a un grupo de objetos como uno solo. Entonces habría algunos objetos complicados como polilíneas, anillos, toros... y así sucesivamente. E incluso los objetos de algún panel de control podrían fusionarse. Y Ctrl-B no produciría una hoja de objetos, sino nombres ordenados de grupos de objetos, o algo similar. Además, el problema de obtener 100000 eventos de objetos modificados en el manejador OnChartEven() se resolvería, porque estos 100000 objetos podrían fusionarse en un grupo y recibir un solo evento CHARTEVENT_OBJECT_CHANGE. En definitiva, sería una belleza. Por supuesto, se puede implementar parcialmente todo esto a través de clases, pero no todo.
Lizar:
........ Y Ctrl-B daría no una hoja de objetos, sino nombres ordenados de grupos de objetos, o algo así...........
....... ya que estos 100000 objetos podrían combinarse en un grupo y recibir un solo evento CHARTEVENT_OBJECT_CHANGE. En definitiva, una belleza.......
Sueña, no te hagas ilusiones.
:)
Estoy escribiendo un indicador para mostrar las velas de varios instrumentos a la vez. Después de iniciarlo y antes de que aparezcan las nuevas barras, todo se muestra correctamente:
Pero tras la aparición de nuevos bares se produce un cambio:
Y ChartRedraw no ayuda. Aunque, si pulso el botón correcto -refrescar-, todo está en su sitio. ¿Pueden decirme cómo evitar el desplazamiento?
¿Está el doble price; normalizado automáticamente en MqlTradeRequest? (lo cual es poco probable) y si no, ¿por qué no hay todavía normalización en la biblioteca estándar? (Esta cuestión la planteé hace 9 meses).
Salí de la situación simplemente haciendo ediciones en la biblioteca estándar, pero sabes que no es el caso (se derriba al actualizar).
Si me equivoco, indíqueme en qué.
No hacemos la normalización de forma automática, ya que no se nos permite cambiar el precio del comerciante para no ser acusados de arbitrariedad.
Tiene que normalizar el precio usted mismo si utiliza el precio calculado. Cuando se coloca una orden con precios netos Bid/Ask sin cambios, la normalización no es necesaria.
No hacemos la normalización de forma automática, ya que no se nos permite cambiar el precio del comerciante para no ser acusados de arbitrariedad.
Tiene que normalizar el precio usted mismo si utiliza el precio calculado. Cuando se coloca una orden con precios netos Bid/Ask sin cambios, la normalización no es necesaria.
Gracias, he encontrado lo que quería. Incluso la oferta y la demanda tuvieron que ser normalizadas en 4.
En realidad, en MT4 no es necesario normalizar la oferta y la demanda. Siempre están normalizados por defecto.
Si tienes un ejemplo a mano, por favor muéstramelo.
En realidad, en MT4 no es necesario normalizar la oferta y la demanda. Siempre están normalizados por defecto.
Si tienes un ejemplo a mano, por favor enséñamelo.