Galería de interfaces de usuario escritas en MQL - página 55
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
También tengo el lienzo a pantalla completa redibujándose completamente cada vez que cambio, pero no tarda más de 50ms...
Lo más costoso es dibujar texto. Por eso, para no usar TextOut cada vez, los almaceno en arrays. Resulta mucho más rápido.
Sí, se usa TextOut . Pensaré qué se puede hacer con él.
Bueno, la simple aritmética funciona aquí: la suma de las áreas de 10 - 17 ventanas es mucho mayor que la pantalla completa. De acuerdo. Más los dibujos secundarios adicionales necesarios para crear sombras, iconos, marcos....
Y sobre TextOut voy a comprobar y escribir. Una idea interesante.
No entiendo tu simple aritmética :). En mi aritmética no hay necesidad de dibujar aquellos píxeles que no son visibles para el usuario, y el tamaño máximo del lienzo para dibujar está limitado por el tamaño de la pantalla en píxeles.
Dibujo en capas, no importa el número de ventanas, todo en un mapa de bits. Puede haber hasta cien ventanas. Las primitivas simples se dibujan en un tiempo minúsculo. Lo más largo, como escribí arriba son los textos. Pero con la ayuda de TextOut en el primer uso, y más allá ya de matrices listo.
Hay que aprobar un plan de trabajo para el futuro.
Publicaré una actualización cada semana. Sábado o domingo.
1. En la próxima actualización publicaré una versión completa del motor. Corregiré errores y aceleraré el renderizado.
2. La segunda versión estará dedicada a las tablas. Restauraré las características básicas.
3. La tercera versión - Voy a hacer tablas dinámicas. Espero implementarlas en una semana. Lo intentaré.
4. Cuarto lanzamiento - ventana dinámica. Intentaré publicar la versión terminada.
En esta etapa, las versiones básicas del constructor, el motor y el lenguaje de marcado pueden considerarse completas.
Definitivamente abriré una rama de plantillas escritas en KIB-code, donde publicaré ventanas terminadas y grupos de elementos. Con ilustraciones para que sea más fácil para aquellos que quieran construir la interfaz.
Y trataré de escribir artículos tutoriales para que la gente pueda usar todo el abanico de posibilidades.
En este hilo seguiré publicando código, imágenes y material explicativo a medida que pueda. Estaré muy ocupado haciendo el trabajo mencionado.
No entiendo tu simple aritmética :). En mi aritmética no hay necesidad de renderizar aquellos píxeles que no son visibles para el usuario, y el tamaño máximo del lienzo para renderizar está limitado por el tamaño de visualización en píxeles.
Dibujo en capas, no importa el número de ventanas, todo en un mapa de bits. Puede haber hasta cien ventanas. Las primitivas simples se dibujan en un tiempo minúsculo. Lo más largo, como escribí arriba son los textos. Pero con la ayuda de TextOut en el primer uso, y más allá ya de matrices listo.
Trabajar con un lienzo grande tiene muchas limitaciones. Ya he pensado en esta opción e incluso discutido con Nikolay.
Me explico: lo haces porque usas la clase estandar Ccanvas. Hay soluciones ya hechas en el marco de las cuales trabajas. Pero yo no uso la clase Ccanvas. Todos los códigos de renderizado son de desarrollo personal. Por eso no me quedo con el concepto - un canvas para TODO. En mi opinión, es una solución técnicamente inconveniente e ineficiente en un entorno gráfico. Es más fácil usar conjuntos de objetos bitmap y adjuntarles recursos ya hechos que tener un bitmap y construir programáticamente la interacción de imágenes sobre él. Es incluso difícil de imaginar. Pero esto no es lo principal.
Imagina cuánto más difícil es realizar el concepto de una GUI multi-ventana si sólo tienes UN lienzo. Yo no me enfrentaría a semejante tarea.
Pero ni siquiera esto es decisivo. La razón principal para rechazar la idea de un lienzo para todas las imágenes: cuando sólo hay un lienzo, mover las ventanas de la interfaz requiere redibujarlas dentro del entorno MQL. En cambio, si cada ventana ocupa su propio objeto bitmap y se mueve mediante la función ObjectSetInteger(), - el redibujado de los objetos movidos recae en funciones estándar que trabajan fuera del entorno MQL. Por lo tanto, es mucho más rápido.
Sólo tienes una dirección de desarrollo diferente en la que otras soluciones funcionan más eficazmente.
Muchas gracias por el consejo sobre TextOut. Voy a investigar este punto.
Las ramas de la plantilla están escritasen código KIB que
Sí, para la depuración implementaré desconectar el programa de usuario del motor, si eso es lo que querías decir. Probablemente lo entendí mal.
Trabajar con un lienzo grande tiene muchas limitaciones. Ya he pensado en esa opción e incluso la he comentado con Nikolay.
Me explico: lo hace porque utiliza la clase estándar Ccanvas. Hay soluciones ya hechas en el marco de las cuales trabaja. Pero yo no uso la clase Ccanvas. Todos los códigos de renderizado están escritos por desarrollo personal. Así que no me atengo al concepto - un lienzo para TODO. En mi opinión, es una solución técnicamente inconveniente e ineficiente en un entorno gráfico. Es más fácil usar conjuntos de objetos bitmap y adjuntarles recursos ya hechos, que tener un bitmap y construir programáticamente la interacción de imágenes sobre él. Es incluso difícil de imaginar. Pero esto no es lo principal.
Imagina cuánto más difícil es realizar el concepto de una GUI multi-ventana si sólo tienes UN lienzo. Yo no emprendería semejante tarea.
Pero ni siquiera esto es decisivo. La razón principal para rechazar la idea de un lienzo para todas las imágenes: cuando sólo hay un lienzo, mover las ventanas de la interfaz requiere redibujar dentro del entorno MQL. Por el contrario, si cada ventana ocupa su propio objeto bitmap y se mueve mediante ObjectSetInteger(), - el redibujado al mover recae en funciones estándar que trabajan fuera del entorno MQL. Por lo tanto, es mucho más rápido.
Sólo tiene una dirección de desarrollo ligeramente diferente en la que otras soluciones funcionan más eficientemente.
Muchas gracias por el consejo sobre TextOut. Investigaré este punto.
Es que NO estoy usando el kanvas estándar :).
Y me pareció más fácil implementar una interfaz multiventana en un solo mapa de bits. ¡Pero cada uno a lo suyo!
Y en la práctica parece ser más rápido redibujar todo el lienzo que usar ObjectSetInteger, etc....